This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: finding a function with address
- To: Michael Elizabeth Chastain <chastain at cygnus dot com>, "Peter.Schauer" <Peter dot Schauer at Regent dot E-Technik dot TU-Muenchen dot DE>
- Subject: Re: finding a function with address
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Tue, 6 Feb 2001 13:01:42 -0500 (EST)
- CC: jtc at redback dot com, gdb at sources dot redhat dot com
- References: <200102051329.FAA31142@bosch.cygnus.com> <200102051025.LAA26655@reisser.regent.e-technik.tu-muenchen.de>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> From: Michael Elizabeth Chastain <chastain@cygnus.com>
> Date: Mon, 5 Feb 2001 05:29:00 -0800
>
> Eli Zaretskii writes:
>
> > Am I using GDB incorrectly? Is this a bug in GDB or in its DJGPP
> > port?
>
> "info symbols" appears to work for me (sourceware gdb, Red Hat Linux 7).
Let me guess: you both use systems where the debug info is ELF (or
maybe DWARF2), right?
I debugged this, and the reason for the different behavior between
"print/a" and "info symbol" is that the latter calls
`lookup_minimal_symbol_by_pc_section' with a non-NULL argument
SECTION; "print/a" passes NULL there. If SECTION is non-NULL,
`lookup_minimal_symbol_by_pc_section' rejects symbol table entries
whose SYMBOL_BFD_SECTION is not equal to the passed SECTION.
Here's the scoop: many debug formats, including COFF, put NULL into
SYMBOL_BFD_SECTION, see `prim_record_minimal_symbol' and all its
callers. This makes `lookup_minimal_symbol_by_pc_section' reject all
symbols it finds, and come up empty handed.
Can someone who knows his/her way inside minsyms.c please suggest how
to fix this? It seems that in its current shape,
`lookup_minimal_symbol_by_pc_section' is too harsh to quite a few
platforms, so I think we'd better change that. Would an additional
test for SYMBOL_BFD_SECTION being non-NULL be okay, for example?