Re: add-symbol-file change in gdb 5.1

[Elena Zannoni <ezannoni at redhat dot com>]

Kevin,
you can supply any section and any address explicitly with the
new form of the command, i.e.:
USAGE: add-symbol-file <filename> <textaddress> [-mapped] [-readnow] [-s <secname> <addr>

You could do:
add-symbol-file foo 0x123456 -s .data 0x123456 -s .bss 0x123456

The syntax of the command was changed to accomodate cases for which
different sections are relocated by different quantities.

Hope this helps

Elena


Kevin Nomura writes:
 > We use gdb to debug homegrown loadable modules that are
 > based on Alpha a.out format.  To tell gdb about symbols for
 > a dynamically loaded module, up to gdb 5.0 one did:
 > 
 > 	add-symbol-file modulefile loadaddress
 > 
 > This established the .text, .data and .bss addresses from
 > the single provided loadaddress, which is the only parameter
 > readily available to the user.  The code that did this is
 > symfile.c:syms_from_objfile().
 > 
 > In gdb 5.1 it seems only .text is established by this form of
 > the command.  The user, following what they are used to, now sees
 > their data symbols flagged as invalid memory or maybe with junk
 > values. This is because all other sections are left at address 0.
 > 
 > The user *could* dump the a.out header and relocate these sections 
 > by hand, then specify:
 > 
 > 	add-symbol-file modulefile .text ___ .data ___ .bss ___
 > 
 > Some questions:
 > 
 > - Am I missing something about the use of the command?  Do standard
 >   loadable modules still behave nicely in gdb 5.1 and this is
 >   specific to my homegrown loader (even though it uses a.out
 >   straightforwardly)?
 > 
 > - From my understanding of a.out and ELF I don't see why the
 >   relocation arithmetic to get the .data and .bss sections is
 >   less robust than for .text.  Why not compute them all, so as
 >   not to expose a user to this?
 > 
 > - Web search gave this reference from a Cygnus developer:
 >   http://sources.redhat.com/ml/gdb/2000-04/msg00020.html
 >   Is this related to the change we now see?  I would disagree
 >   with the statement that the previous mechanism doesn't work
 >   for non-text sections, but maybe this is again unique to our
 >   simple loader.
 > 
 > Thanks for any suggestions.
 > 
 > Kevin Nomura
 > Network Appliance