Debug 101 (v.0.9)

@alfkil

Cool ! Tested new version. For first have crash, but i think it because you forget to replace new binary over the old one in the root of archive (new one are 406kb, old one in root was 365 or kind). So i run that one from "src" directory and all goes well.

Now windowses non-blocking. That very good ! I open register/variables/disassemble window, and then do "step" in main one, and see changes (not in disassemble window through, but that not big deal for now. But will be nice to see some marker, which will point on current executed instructions set).

Also bugs with DSI at open, freeing of memory and "its not a ppc binary" are gone ! Cool ! But stil there is problem when you trying to load any other ppc binary (which not have debug info i think) in that "stabs_make_function_list()". and still problem with non-proportional fonts. Its still un-bounded :( Maybe there need some more settings for .. Maybe salas00 can give us a good code-example ..

In others, you make really good progress. I already do some debug stuff over it, and understand for now one bug in my programm, which i detect by checking what registers have and where point instruction pointer :)

Now, if you not scare to much, and still have some motivation , and you will not fear by long post, i will write some ideas , which maybe you will found interesting (very possible that not, so just skip it if so :) ):

1. Registers window.

I think we can design it a bit, just for make it a bit "human readable". On ppc-macos, back in times i did for yourself such table:

Quote:

For sure for aos4 its different, but still there is should be any logic (because of all C compilers and the same ways of argument passing). It can be redesigned like: "system heavy" registers at one table/row (like ip/cr/xer/ctr/lr/msr), "user kind" register at other table/row, which can be splitted also on those which are used for arguments usually (when they passed over stack) and so on. That maybe not big deal, but will be pretty user-friendly, because someone can not know how all the registers used on aos4, and will be nasty to understand it just by watching at registers window.

2. Disassemble window

Maybe there will be good to add like in GDB not just offsets, but function name + offset.

I.e. for now it like : 0x7fc7223c (0x0): stwu r1, -32(r1)
but do it like: 0x7fc7223c (function_name+0x0): stwu r1, -32(r1)

That can be also more friendly and understanable. Also as i say before, maybe will be not bad idea add some mark (or highligthing, or any other way) to show what instruction are in execute for now.

And few feature-requester, which of course, you can just put to to-do list, or ingore at all :)), so:

1. Indicate somehow in breakpoint window, where breakpoint was sets. I.e. mark it somehow, and show it all the time somethere.

2. maybe in disassebler window, also make such list as in "hex-viewer" window, but, with list of all used fucntion in the current source. Maybe it will be handy.

3. add interactive mode-window. I.e. when user press "interactive mode" button, he will have some kind of "debugger shell", in which, he can operate by some commands with memory areas/etc. Maybe the same way as for GDB will be good ? (just add all what is necessary in real). Something like:

x/20 0xXXXXXXXX, will dump that and that
d/10 0xXXXXXXXX, will dump that and that

i.e. just like in GDB by logica, but of course commands can be different and more "human-readable", like: hexdump <address> , show bp, show blalbalba, and so on. And by "help" command show all the possible commands.

The window can looks like this:



Maybe it can be nasty (because you will not need to build GUI windowses for all the oprations, but for some you can just use command line as in GDB).

For example by that "interactive window", you can add all of this which already done by gui, + commands for dump any memory/any area, in hex or in disasseble format. Like GDB in other words .. Dunno maybe of course will be better to do everything the same (like only GUI + mouse, and not interactive), but maybe interactive mode will help a too.

All in all, all of this only "maybe" and "if you in interest to add", because debugger already good and usable.

PS. imho you should suggest a bounty on AB, and i will make few news-posts on amiga-related sites, just to fill up bounty a bit, and make your motivation up a bit more. And imho you can also start to upload it ot os4depot as well, because it good and usable already :)

Just for some fanboyz purposes found in the google nice images which can be used as icon for the debuger (while mason not done one:) ):





There is native aos4 icons from these images (64x64):

first one
second one

@salass00

What I meant to say I guess was, that I'm using the reaction default font. Which seems to not necessarily be the same as the system default. Now I know the difference, thank you .

@alfkil

In the meantime I have run into a catastrophical problem (one more besides the elf.library thing...):

Setting the msr |= MSR_TRACE_ENABLE (0x400) from the exception context doesn't work . This means, that I'm not going be able to do proper handling of loops etc before that is fixed. This is probably the very same problem that keeps GDB from being remotely functional.

Just to explain: Setting this processor flag should make the processor yield an exception after executing exactly one instruction. Of course I can easily install a TRAP instruction on the next coming instruction, but this doesn't take into account, that the processor might do a branch during that very same cycle. Doing a trace would automatically leave the ip at the branched address, but to be able to do that with a patch would be breaking an arm and a leg. Doh!

Help needed.

@alfkil
Tryed to test it as hard as i can, and found 2 more UI bugs:

1. press select file, but not choice any file, and pressing chancel button or close gadget give DSI.

2. select file (hello word for example), press BP, choice any BP, press "start",then again press BP, and trying to press "step" in main window: window blocked. Then press close in the BP window, and DSI, with stack point on step()+01c (section 1 @ 0x10c4), which show by addr2line on suspend.c file at line 331.

New version uploaded (see original post).

This one is by far the hardest one I've done yet, especially because of the msr register bug that I came across. Arghh!

@kas1e
I think I have fixed most if not all of the bugs, that you have come across. If not, please let me know. And once again I really appreciate your hard work. And really, you don't _have_ to download and test _every_ single upload that I do (there are going to be plenty more I can assure you), but it actually really helps a lot. (BIGSMILEY )

@alfkil

No problems , i in high interest personally to have debugger on os4 :) Every update are worth of testing , because you change/add things fast :)

Btw, how you fix your msr-bug problem ? Some workoraund or you found how to do it "right" ? And by the way, are you betatester ? (i mean if you found a bug in elf.library.kmod already, can you report it internally and be in hope that it will be fixed soon, or, you need to annoy someone from beta-test-team to have a looks at this, and report to bug-report-list) ?

@alfkil
Tested new version:)

New step over disassemble are cool. Now i can step not only through C lines, but also over assembler instructions, what is pretty handy, because developer can understand on what moment exactly registers was changes, and what instruction cause it.

Also now i can load any binary (even without debug information), but BP window show nothing in that case. But still, there (in any binary) "_start" and few other fucntions are present, and maybe it possible somehow to show it as well ? I mean make possibility to works with binaryes which even not have debug information. Of course it will be suck, and you cant debug everything in "good way", but still, developer can try to do steps and breakpoints from the begining, and step-by-step found bug even without debug information.

For example, when i load Filer binary (without debug information) to GDB, it says:

(no debugging symbols found)

(gdb)

But still you can do for example

(gdb) disass _start
Dump of assembler code for function _start:
<xxxxx> xxxxxxxxx
<xxxxx> xxxxxxxxx

(and at this point , aos4 version of GDB happyly crashes btw :) (i use your latest build) And it also crashes on any binary ! For example try to load to GDB your helloword, and do: "disass main", and you will have crash in the gdb:dump_inst()+9x1bc (section 1 @ 0x541fc), and addr2line point on disasm.c:137. Maybe you can upload your latest GDB source, and i will try to fix it myself (or maybe you can do that ?:) )

Anyway, when it works as should (GDB i mean), that "disass _start" even for binary which not have debug info will show you addresses from which your binary are loaded in the memory, and you can understand already in which memory areas binary are placed, and you can try to hexdump something, you can set breakpoints on some addresses and so on. If it possible to add (later, for todo list, maybe:) ), then it will be nice too (imho). Maybe even GDB code can help us (we can just rip off some pieces of code from).

Also i found few bugs :) :

1. hex-viewer window still with unbounded text (i think you just not change it for now, so not "bug", just something to fix later, and all in all not so important for now)

2. select file "db101", BP at main(), start, give DSI in the db101:strip_for_tabs()+0x60 (section 1 @ 0x2828). addr2line says: gui.c:146

3. still BP window are block other ones, and and give you DSI if you press on main window buttons when BP window are active. How to reproduce:
-- select file "helloword".
-- set break at "hello", select
-- start
-- spawn set break window again
-- press on the "step" in the main window while that BP window are active.
At this point button "step" in the main window will be pressed, but nothing will works (i.e., like action not have place). But visually button pressed. Then you press on close in the BP window, and have DSI in the insert_line_breakpoints()+0x24 (section 1 @ 0x8a04). addr2line say: breakpoints.c:101

Hope that help :)

@kas1e

Quote:

This is really strange. I have changed it to the courier 15 font, and here it looks absolutely straight. Do you have courier installed in you sys:fonts??

Quote:

Hmm, I'll take a look at it.

Quote:

I know about this, and I'm going to have to do a complete redesign of the breakpoint window to facilitate multiple breakpoints, deletion of breakpoints, setting of breakpoints at individual lines (and maybe a checkbox to optionally include normal symbols as well). Until I get around to doing this, try to consider the breakpoint window a "requester", that needs to end before the rest of the program continues.


About GDB, I'm not to be considered the person responsible. I could probably have fixed this, but I messed up something in my local GDB directory, and now I can't compile the damned thing. Try writing to Sebastian Bauer, as he has fixed some things in GDB before.

Version 0.7 of DEbug 101 has been uploaded. See original post.

@alfkil

Quote:

Do you have reported this problem to the AOS4 developpers or on the AOS4 feedback thread, on amigans ?????

@alfkil
Quote:
I think so (can't check for now, but i think its default?). Maybe you can do it as Salas00 suggested and it will solve the problem ? Anyway, maybe better skip it for now, there is for sure much more interesting/important things which need to add for debugger :)

@Mrodfr

Quote:

"Or with the latest beta version (53.13)."

ps. can you please write one time "?", but not "??????" ?:) Because for such questions only answers like "because !!!!!!" can be :)

@kas1e

Quote:

????? Because I really really would like to use this tool with the next AOS4 version

I don't own AOS4.0, just AOS4.1 and more...

@Mrodfr

No one referred to AOS 4.0 except you. I think you didn't understand well what alfkil said : DEbug 101 will not work under AOS 4.1 update 1 nor under AOS 4.1 update 2 due to a bug in elf.library on this systems. On the other hand elf.library.kmod from a *plain* AOS 4.1 (no update installed) doesn't contain this bug (as the latest - yet unreleased - version v53.13) and will enable to run the program.

So if you really want to run this debugger then either replace your elf.library.kmod by the one from the AOS 4.1 CD (not very advised, as you'll loose the features introduced since then at the same time which might very well prevent some other programs to run reliably or run at all) either wait for an update with the latest elf.library (advised).

@abalaban

Thanks for the explanation. I could test (hum....use) debug101 finally

@alfkil

Quote:

Such tool is nice but id doesn't help if you want to debug a library because you can't just run it.
I would prefer something integrated into gdb that you can use everytime.

@Elwood

How would GDB be able to debug a library? And are you thinking about a normal amigaos library or a shared object? As far as I can see, gdb would come with the same limitations as db101 in this regard, due to the limitations in the exec debug interface. I could be wrong, though.

@alfkil

How one can debug a library without a corresponding executable ?
I don't remember well as it's a long time now that gdb doesn't work anymore under AOS 4.x (pre 3 ??) anyway IIRC having a library compiled with debug info would allow you to debug its functions while you were attached to a using exe.

The advantage of GDB over DEbug 101 is that it can (theoretically) attach itself to an already running process, that's a huge thing IMHO.

@alfkil , abalaban
I think Elwood mean ability to load xxx.library and xxx.so
to debugger (with debug info, or without), and then, if it was with debug info - give you all the info about, and give you ability to navigate over hexdumps/code/disassembler.

In the most advanced way, xxx.library or xxxx.so can be not only loaded, but also "running" to some virtual memory space (to not affect whole system at all), and debug (with all those Steps, BreakPoints) these functions, which are library/so related (for make lib/so works at all. I.e. loads, removes, be "resident" ), but not these fucntions which provided by that lib or .so for user (only making a list of them). Because how you can debug the function in library, if none of program use it.
Of course, even it that case, it possible to create some way, to debug even these "users" functions in libs/so. Like "if user put in the directory xxxx.exe and xxxx.library, then, debug library functions"

That all imho not so easy task, and on that stage are not important for sure. But something like this can be interesting too of course.

For example, i found that link about "how debug shared libraryes on GDB"

There is described some way how all of this works in GDB, so i think the same can be done and for .so, and somehow for .library, but that is 100% not easy.

@kas1e

It seems that yes. I'm not a expert but as far as I understand you can debug anything with GDB. When a process crashes, you attach the process to GDB and you can navigate forward or backward in your code.