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]
Other format: [Raw text]

Re: find_pc_partial_function may produce the wrong answer


>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> Is the shared library stripped?  I am absolutely positive
 Daniel> that the minimal symbol table will include the static symtab
 Daniel> - as long as there is one.

Found the problem.

The NetBSD build procedure for libraries has a rather peculiar compile
step, which includes running the file through ld with a -x switch.
That will do it...  It's not supposed to do that if a -g is present in
the compile options; that may be an error in the top level build
process at our end.

That does leave this puzzle:

Given such a shared library (no local symbols in the symtab),
"disassemble somestaticfunc" works fine if I open the shared lib
itself with gdb.  But if the shared lib is referenced via the shared
lib symbol load machinery, for example because a corefile pointed to
it, then the same disassemble command doesn't work.

It looks like the code in blockframe.c that pulls in the psymtab to
double-check the function (if an end address was requested) doesn't
work in that second case.  Does that make sense?

     paul


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