On Wed, 2009-03-25 at 22:40 +0100, John Tytgat wrote: > In message <1237983394.18642.36.ca...@duiker> > John-Mark Bell <[email protected]> wrote:
> > As it stands the current design of GDBServer is very much geared to > > normal applications. Modules should be possible, assuming you've got a > > sufficiently modern OS version (likely sit on the pre-init and > > post-final services). > > Maybe a different approach is more feasible: one of the last steps > in the module creation process is to copy out the binary object blob > out of the ELF file created by the linker. In this process, the > DWARF data gets dropped. > > I'm wondering if GDBServer can't be teached to process this ELF jacket > wrapped module himself allowing access to the DWARF data. And it could > link and delink the module in the module chain itself too instead of > letting RISC OS doing this. I guess that could be made to work. GDBServer itself couldn't care less about the debugging data -- that's the responsibility of GDB itself (this is why you can happily debug a stripped binary on a remote host if the machine running gdb has a copy of the unstripped binary). How much processing would be required on the ELF-wrapped module to get it in a format RO will cope with? Is it overly naive to hope that it's simply a case of calling the "load module from memory" OS_Module reason code with an appropriate offset into the memory-resident binary? J. _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
