As far as i know, GDB will debug for you only binary on os4. I.e when process crashes, and if crash only in the library, then gdb can not be attached.
And even if GDB on os4 can debug .so, its imho cant debug .library at all.
That can be good addition if debug101 can debug later as well as .so, as well as .library :)
While debugging of .so can be done the same way as it done in GDB, for .library, we can go or almost the same way, or the way as Olly-debugger (win32) debug .dlls(why i say about dll, because it the same as .library in general):
1. you load program which use some .dll (of course dll and program should be compiled with debug info, for allow to do all those source-level debugging).
2. press alt+e , and you have window with all the libs (dll) which are used by your loaded binary to debuger.
3. choice any .dll, press enter, and you inside the dll code. Set breakpoint on anything you need, and then, run the main loaded program, and it will Breaks on DLL code, and you can debug it.
The same way can be done for .library on aos4, and while its nice addition (and will help developers pretty well) , i not sure how easy it will be to implement.
@alfkil How hard you think will be add that ? I mean user load binary, and you have some button for list "libs" (or maybe list+sobjs) which used by binary. Then, choice any library/so will jump you on code of library (with debug info from), and then BP, run main program, and so on.
@all Btw, i do not remember, but did any debugger on os3 debug libraryes ? SAS-C debugger maybe can do that ?
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
That is also going to be possible with db101 in the future.
@Elwood Quote:
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.
Debugging of libraries is currently _not_ possible in the amigaos version of GDB. The reason for this is, that there is no API for it in the exec debug interface. If such an api is added, db101 will also be able to debug libraries.
Currently the only thing possible (with GDB or db101 when it is implemented) is to step through the assembly of the library or shared object, but it is not possible to read the debug info.
alfkil wrote: Debugging of libraries is currently _not_ possible in the amigaos version of GDB. The reason for this is, that there is no API for it in the exec debug interface. If such an api is added, db101 will also be able to debug libraries.
Currently the only thing possible (with GDB or db101 when it is implemented) is to step through the assembly of the library or shared object, but it is not possible to read the debug info.
Why exactly do you need special support for it in the exec debug interface? When I get a crash in a test version of minigl.library, I can get the line number using addr2line (via minigl.library.debug as the actual library doesn't contain the debug symbols). It seems to me that all the required information is already available. All you need is a library with debug symbols (or a .debug file if you work the way that I do), and the source-code.
Obviously, if the library/shared-object has been stripped of debug symbols, and you don't have them in a separate file, then there will be no way to step through the source-code, but this is true of any executable.
How does the grim-reaper extract its information? It's pretty clear that it's there.
Trap type: DSI exception Machine State (raw): 0x200f030 Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on] Instruction pointer: in module kernel+0x19d6c (0x1819d6c) Crashed process: db101 (0x65023b60)
That with usage of elf.library.kmod from quickfix update (which i use later for all the tests). Imho very possible that at this point only new beta-version of elf.library.kmod are need it ?
Ok, you have a point here and I'll have to modify my statement:
It IS possible _once you're inside the library_ to call IElf->OpenElf (OET_MemoryAddr, ...) and thereby get an elf handle, that you can then use to extract the debug info.
It is NOT possible to load up your executable and straight away set a breakpoint inside a shared object, because there is no way to get a list of elf handles to the shared objects used by your executable.
There IS a tag in the debug hook that allows you to know every time your executable loads a standard amigaos .library. But there is no such tag for shared objects. Also, if you attach yourself to an already running process, there is no way to get a list of already opened amigaos libraries.
Again I was a little too quick on the trigger, sorry! I have uploaded a new version, that also solves a problem when debugging db101 with itself :)
Yep, now all is fine here , thanks for fix :)
But found one more UI bug: pressing on the close gadget of main window, while disassemble window are active give a lockup. How to reproduce: load any binary, set any breakpoint, start, spawn disassemble window, and press close gadget in main window - debugger will quits, but disassemble window will still stay open, and after a while give lockup. All other windowses (registers, globals and so on) not have such problem.
Also when you press "generate stack trace" it give DSI by memguard at some stage, but i think its because that option are in progress. Anyway, reproducing are easy: select file hello word, and then press "generate stack trace" , give DSI with such output: Quote:
Trap type: DSI exception Machine State (raw): 0x200f030 Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on] Instruction pointer: 0x7ec30700 Crashed process: db101 (0x667f9350) DSI verbose error description: Access not found in hash or BAT (page fault) Access was a load operation
2) Stacktrace is junk, because I don't know how to do it. I'm waiting for help from os developer team (ssolie), but I think they are busy with other stuff.
3) There is a bug in the linker (dl) that leaves out a bunch of debug info from the final executable. What this means is, that if you are compiling multiple files into one executable, you are not going to be able to read the typedefs properly. So when the "Locals" or "Globals" windows just show you "UNKNOWN", this is _not_ my fault, it is a bug in the linker... Doh!
I don't know if it's the info you're looking for, but for PPC EABI stackframes are single-linked in a chain, you can handle them using (e.g.) the following header:
As for the debug symbols, make sure to use -gstabs especially for larger binaries.
Btw, there any other way that -g/-gstabs for adding debug information to binary ? As i know there is only one way (-g and -gstabs), which imho not matter large binary or small (if coder add -g or -gstabs , debug info should be provided without matter of size of binary imho). Also i think all the time that -g and -gstabs its absolutly the same (just -g its short version of -gstabs).
So, if alfkil have any debug info already, than imho mean that he already add that info by that -g/-gstabs.
-gstabs is already there, the problem is, that the linker leaves out any info from include files except for the very first file to be linked. Ot at least that's what I think is happening...
First I do this:
gcc -gstabs -S somefile.c
... and all the info is right there in place. Then I
gcc <the whole project> -o myproject
... and then I load myproject into db101. Then I print every stabstr there is, and all the include file data is now gone. Gone is therefore also any typedefs (and structures), that might occur inside one of the include files. This is nasty, and I sincerely hope, that someone can fix it...
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
.
.
