@alfkil Tested v0.8. BP no more blocked - cool :) New "attach" looks interesting. I attaches to OWB for example, but because it not have debug info, it show me no info in BP/etc windowses. So i trying to attach to db101 itself, and it works :) Show me functions in BP window and i select BP at "step", but cant debug the same version of debugger over the same debugger at time :)
Then i compile AmiFig with debug information, run it, and trying to found it in the attach list - and cant. I can see by "process" command in shell that i have AmiFig in memory, but in attach window i not have it. So, i trying to load it just to debugger by "select file" (to test that it loads fine), and debugger say for me:
Quote:
trying to attach debug hook... debug hook attached! Executable section (0x1000074/403064 bytes) starts at 0x7f991020 Relocating section ".debug_aranges" (index 16) which is referred by section ".rela.debug_aranges" (index 17) Relocating section ".debug_pubnames" (index 18) which is referred by section ".rela.debug_pubnames" (index 19) Relocating section ".debug_info" (index 20) which is referred by section ".rela.debug_info" (index 21) Relocating section ".debug_line" (index 23) which is referred by section ".rela.debug_line" (index 24) Relocating section ".debug_frame" (index 25) which is referred by section ".rela.debug_frame" (index 26)
And then crash with such MemGuard output: Quote:
Trap type: DSI exception Machine State (raw): 0x200f030 Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on] Instruction pointer: 0x7f9f368c Crashed process: db101 (0x669e21a0) DSI verbose error description: Access not found in hash or BAT (page fault) Access was a load operation
So, maybe its the same problem because of which its not shows in the Attach window ?
I also trying to load debug version of SuperTuxKart game, and have: Quote:
trying to attach debug hook... debug hook attached! Executable section (0x1000074/3914924 bytes) starts at 0x7f638020 Relocating section ".stab" (index 23) which is referred by section ".rela.stab" (index 24) Relocating section ".debug_aranges" (index 27) which is referred by section ".rela.debug_aranges" (index 28) Relocating section ".debug_pubnames" (index 29) which is referred by section ".rela.debug_pubnames" (index 30) Relocating section ".debug_info" (index 31) which is referred by section ".rela.debug_info" (index 32) Relocating section ".debug_line" (index 34) which is referred by section ".rela.debug_line" (index 35) Relocating section ".debug_frame" (index 36) which is referred by section ".rela.debug_frame" (index 37) Relocating section ".debug_loc" (index 39) which is referred by section ".rela.debug_loc" (index 40) Relocating section ".debug_ranges" (index 41) which is referred by section ".rela.debug_ranges" (index 42)
And then crash, but at this time with GR. And stack trace looks like this: Quote:
1. Select file, press "hexview" button give lockup of whole system.
2. You cant load any file from the root of any partition (it say File is not executable). So, user/devloper need to put it to any directory to make it works and loads.
3. Btw, i also not found how to deactive my attaching (to continue works with other files). And if i exit from db101 after attaching to OWB, then, OWB can not be closed later.
Edited by kas1e on 2010/10/7 10:45:02 Edited by kas1e on 2010/10/7 10:47:22 Edited by kas1e on 2010/10/7 10:58:15 Edited by kas1e on 2010/10/7 11:00:14
Your three wishes have been resolved . Hexview is now functional again, root path is recognized and you can de-attach yourself from a running task by simply exiting db101. Hope this helps.
About your issue with AmiFig and SuperTuxKart I have no idea what is causing this. The relocation code is stolen from GDB, which means I don't really know how it is supposed to work. Also it is very strange, that you have section names like ".debug_smthsmth" and ".rela.debug_smthsmth"...?? This is definitely not stabs info, so what is it?
About finding tasks in the process list, you are probably looking for a process named "Background CLI", since that seems to be the default name for cli processes started from the Workbench.
Your three wishes have been resolved . Hexview is now functional again, root path is recognized and you can de-attach yourself from a running task by simply exiting db101. Hope this helps.
Awesome ! All works fine now, yes !
Quote:
About your issue with AmiFig and SuperTuxKart I have no idea what is causing this. The relocation code is stolen from GDB, which means I don't really know how it is supposed to work.
For example i tryed to load debug version of amifig to gdb :
So it loads fine with GDB (good to know that bug is not in OS :) ).
Quote:
Also it is very strange, that you have section names like ".debug_smthsmth" and ".rela.debug_smthsmth"...?? This is definitely not stabs info, so what is it?
Hm, i not ELF guru too, so cant say. More of it i not so good understand how you parse debug info at all :) Only some "stabs" related info ? Btw, maybe it helps, that how looks like compilation line for AmiFIG: Quote:
If you can explin in brief in more or less human words how you read debug info for now, it will be very helpfull (i will try to research it a bit too).
Quote:
About finding tasks in the process list, you are probably looking for a process named "Background CLI", since that seems to be the default name for cli processes started from the Workbench.
What a bit hard here for now: its that i have about 5-10 background CLI tasks :) Maybe it is possible somehow to "grab" the name and write it like : Quote:
Of course for now all that "design" work not so matter (all of this can be done later), but if it will be not so hard will be good too (just easy for developers to found the stuff).
EDIT: btw, found how AmiFIG called in the Attach list - "shell process" (i run it from the cli). So, next i trying to attach, and the same: Quote:
attaching to process with name Shell Process Suspending task 0x6686a5a0 task suspended! trying to attach debug hook... debug hook attached! Executable section (0x1000074/403064 bytes) starts at 0x7f9a0020 Relocating section ".debug_aranges" (index 16) which is referred by section ".rela.debug_aranges" (index 17) Relocating section ".debug_pubnames" (index 18) which is referred by section ".rela.debug_pubnames" (index 19) Relocating section ".debug_info" (index 20) which is referred by section ".rela.debug_info" (index 21) Relocating section ".debug_line" (index 23) which is referred by section ".rela.debug_line" (index 24) Relocating section ".debug_frame" (index 25) which is referred by section ".rela.debug_frame" (index 26)
And GR with pointing again on the same stack trace: Quote:
So, its the same get_symbols() stuff as in case with SuperTuxKart (what is good - the same bug then for boch bins).
Should add that all that attaching stuff are very usefull. It will help a lot to understand where is bug, when you only can see it visually. I.e. attach, BP, and then step-step to the final end. That really cool.
@aflkill Ha ! I think i found where the problem: -g and -gstabs are _different_ !
When i compile hello world with -gstabs, it says: Quote:
trying to attach debug hook... debug hook attached! Executable section (0x1000074/724 bytes) starts at 0x7eb99020 Relocating section ".stab" (index 9) which is referred by section ".rela.stab" (index 10)
And all works fine (BP have info and so on).
But if i compile it like : -g , then debugger says on load stage: Quote:
trying to attach debug hook... debug hook attached! Executable section (0x1000074/724 bytes) starts at 0x7eb9a020 Relocating section ".debug_aranges" (index 10) which is referred by section ".rela.debug_aranges" (index 11) Relocating section ".debug_pubnames" (index 12) which is referred by section ".rela.debug_pubnames" (index 13) Relocating section ".debug_info" (index 14) which is referred by section ".rela.debug_info" (index 15) Relocating section ".debug_line" (index 17) which is referred by section ".rela.debug_line" (index 18) Relocating section ".debug_frame" (index 19) which is referred by section ".rela.debug_frame" (index 20)
And BP are empty, and so on.
So, that -gstabs and -g are different, and maybe one more for todo to handle -g stuff too :) If addr2line works with "-g" and GDB looks like too, maybe it will be not very hard to add (but if it is, then just for TODO, or just skip it at all and add to readme that only -gstabs can be used).
With -gstabs+ (there is also such combo too), it loads fine too, but BP window a bit fucks with it.
That what i found in the google: Quote:
-g Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging information. On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).
GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
The following options are useful when GCC is generated with the capability for more than one debugging format.
-gstabs Produce debugging information in stabs format (if that is supported), without GDB extensions. This is the format used by DBX on most BSD systems. On MIPS, Alpha and System V Release 4 systems this option produces stabs debugging output which is not understood by DBX or SDB. On System V Release 4 systems this option requires the GNU assembler.
-gstabs+ Produce debugging information in stabs format (if that is supported), using GNU extensions understood only by the GNU debugger (GDB). The use of these extensions is likely to make other debuggers crash or refuse to read the program.
@aflkil But even with -gstabs the problem is still here. I recompile whole amifig with that line:
Quote:
gcc -gstabs -O2
And when i do select file in debugger, i have:
Quote:
trying to attach debug hook... debug hook attached! Executable section (0x1000074/401720 bytes) starts at 0x7f74f020 Relocating section ".stab" (index 15) which is referred by section ".rela.stab" (index 16)
So looks like db101 already skip that information about these .debug sections (or maybe used it as GDB use , if its the same source-rip from gdb?) And crash is related to something else .. If it will helps i can send you the binary.
Imho, it not crashes for the hello-world just because hello-world are small. db101 itself are not so big too (by functions). But looks like when there is a lot of stuff, something going wrong on parse-stage, and bbbaahh :)
Yeah , problem solved. Now everything loads and can be seen when i compile with -gstabs. I also compile supertuxkart with -g options, and it also loads fine , but i cant see of course in BP any fucntions, but i can see these 2:
__mgl_init_semaphore __mgl_term_semaphore
and in the console: blablabl calling ScanSymbolTable... done! global variable mini_CurrentContext at address 0x5a134218.
so its still trying to parse something even with -g ?
Will do more heavy tests for now, and write you back :)
ps. "attach" mode indeed very important and usable (i not think about how nasty is it before).
@alfkil Found little bug: when you choice in attach any app, app looks like already in "pause" mode (but you not press start , so imho should be not?). And if you exit from debugger (without pressing start button on attached process), debugger quits fine, but app which was attached, start to be in "pause" state.
Or, if you for example attach the app, then press start, works with it, then press Pause , and after that pressing Kill, it again still in pause state.
Looks like you just forget to "unpause" for "kill" and for "exit" from or kind ?
Btw, how hard you think will add "changing" of the data in widowses such as hexview/registers/locals/globals/disassemble ? I.e. user press for example on register data in regiser window, that area highlighs, and user can rename the data inside. Then enter, and data are in register. And the same for all possible windowses where data can be changed ?
Could be possible. I'm a little tired right now, though, so maybe next week some time
Also, there are higher priority stuff like getting the typedef stuff to actually work correctly. It't pretty hard, since I have to invent everything from scratch.
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
. Hexview is now functional again, root path is recognized and you can de-attach yourself from a running task by simply exiting db101. Hope this helps.
