Db101 betatesters needed

@Thematic

It does work with odyssey if you spoof as iphone.

@Rigo

Have you read the documentation? I think, it is pretty clear, what it is doing. I have tried modeling it after the interface in a very old version of x-code tools for mac os x. Of course, you have to do a little work to get it right: The program needs to be able to find the source files. There are actually tools in the program, that will take care of this, if the source path is different from where the app is located. Go to the menu, select "Modules..." and see, if it makes any sense to you. Usually you are also prompted to locate the source, if it doesn't find it right away.

It could be cool to get hands on your testapp and see, if I can make sense out of it not working. Also remember, it only understands stabs (read the manual), so if you have, say, dwarf 2 symbols, it is not going to get you very far. Still, if you run the app and it crashes, you should get a stacktrace and minimum functions like disassembler (basically the same as GrimReaper, although you can do asm steps and restart the app and shit).

Let me know if this helps.

@Alfkil
Downloaded, will test later as my X1k is busy at something else.

Did you manage to fix the issue where only the first break point ever works? IIRC gdb had that issue too... (though not in the old days on my A1XE).

@broadblues

It is fixed .

@alfkil
I do test it on winuae with latest os4, and all seems to works. At least brief tests on helloworld from src/ directory and some breakpoints works, and produce stack trace ! :)

Did you have any plans to extend it futher, or, you ready for suggestions ? You know, i can spam you with suggestions :)

@kas1e

I would, of course, love to hear your input :). If you want to be a little strategic about it, you could wait until just after 10/1-2017, where I have a few days with nothing in the calendar. ;)

@kas1e

On second thoughts: I would love to hear your input asap, so I can think it over thoroughly .

@alkfil
Ok, there you go then:)

1). I do not know if that make much sense, but maybe some tooltype like "MODE=standalone" and "MODE=split_windowses" will be good too, so you will have or everything in one single window (as it now), or, every area will be as window (as it was at begining). So devs can group-regroup it as they wish.

2). Add ability to change data in the Hex Viewer. And there need some advanced way: currently, you can mark only whole lines (address, offset, hex avia and ascii view) at once. Will be good that it you can add there such functionality:

-- if you dbl-click on any hex value, it is change color (to the green for example), and you can edit values right on the address. Without additional windowses, but just right in the same window. Like inline editing.

-- if you dbl-click on any ascii value (that second field), then you can edit it the same way as when you dbl-click on hex values. Without spawning a window with question about what value we want, but , inline editing.

-- add "drag" lines between address , offsets, hex values and ascii values , so developer can resize it all as he wish.

3). "Change symbol value" on the registers do not works (nothing happens), but, there is also have that window with "to what symbol change" are not necessary and one more unnecessary step, instead , inline editing (right when you dbl-click on field) is much better.

4). Basically all the things which we can change, should be inline editing after dbl-click on them. I.e. it highlights somehow, or cursor start to be visibly in them, and so you can delete/skip/write new in. Just usuall inline editing.

5). Assembly window: also will be good to have drag bar for resizing between address, offset and assmebler calls. So user can resize fields as he wish

6). Add in general drag-bars between all windowses (if current mode is only which will be). Because for eample for me, Assembler window is too smal. I want to make it much bigger, on whole screen, to see as much as possible at once. Probably there is that way about "MODE=windowses" , is solution, so everyhting can be resized and regroupped. If that another mode is not in interest , then at least whole main window should have ability to be regroupped, resized in any way user wish.

7). Add some functionality as in dopus5 for example , where you can create a your own window (buttons-bank), in which you can create any button you want, and attach to it any thing you need (arexx, db101 commands, system commands, whatever else). Of course, if you in interest to work on that, i can help with testing a lot.

That all at moment from brief look :)

@Alfkil

I'm no expert/developer but it's great to see a source code being debugged on AmigaOS.
I tried with the helloworld example but I have to read the guide before trying breakpoints and all... I had a crash so I'll try to reproduce it and report.

Thanks for the feedback! I will try and find time to look at it .

@alfkil

Finally had time to try it out. It's working really well on my X1000.

It missing just one thing that I can think of the abilty to move up a down stack frames and analize varaiables there.

Also the abilty to evaluate expressions would be good.

These are the things I use in GDB (as much as it ever works!)

GUI wise having seperate Step etc buttons for the assembler window confused me at first, I didn't spot the src level ones at the top, might it not make sens3e to put those (Continue Kill Step Over Step Inot Step Out) just under the src area?

Horizontal scroller in the src area might be useful for heavily indented src code sections.

Good job though, can't wait for a crash now

@broadblues

Thanks for the report! I will see how much of the incomming suggestions I can manage to implement. Right now there are a few pressing issues with Qt, so this one comes in second. Good suggestions, though! :)

@alfkil

Crash when clicking on "variable"

I let db101 work on a crash i get with ScummVM and a game.

Once the program crashed i can click on "variables" (top right) to bring up their underlying list.
The "list" opens blank and right after that db101 crash, reproducable, everytime.

I know this crash from earlier versions, actually i think i was never able to open such lists and see the entries.

Addr2line gives me this additional info, not sure if it helps though:

addr2line --section=.text -C -fe db101 0xEB20

params_populate_list
variables.c:749

There's also ABADCAFE in the registers...

@kas1e
Quote:
I use an old program called "ScriptLauncher" from OS4Depot that is a button-bank. The need to edit the prefs file manually probably discourages some people from using it.

@alfkil

Quote:

For now I'd be happy if I could get some info somewhere what 'db101' is about...
I read the entire thread, but still am not sure what's it all about.
Before I download to test it, I'd like to know what's it about.

Is it a sort of compliler?

A link leading to a project page with further info would be nice...

A quick Google search for "db101" brought up this (and I don't think your file is somehow related to locomotives):
DB101

@Dandy

It's a debugger, just like gdb, but ... modern

@Dandy

'Deutsche Bahn 101'.... Hahaha!

Db101 is a program, that lets you analyse the execution of other executables while they are running... sort of. It lets you set up markers in the code, and when the executable runs into these, it will stop, and you can see the value of variables on the stack and heap. Not very interresting if you are not a coder. :)

@alfkil

Did you see my crash a few posts above?

@Raziel

Hi Raziel,
I have overlooked that, sorry. At the moment, though, I am very much occupied with other things, so it is going to take a little while, before I can look at it. There are probably a zillion such problems with db101, just not many people using it, so they don't surface so often. I mostly just see it crash, whenever I try it out on a new project. So for sure lots of stuff to do still.
Thanks for the report, I'll see, what I can do :).
/A

@alfkil

Thank you