This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
add-symbol-file change in gdb 5.1
- From: Kevin Nomura <nomura at netapp dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 09 Apr 2002 13:55:36 -0700
- Subject: add-symbol-file change in gdb 5.1
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