This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: finding a function with address


> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]