find_pc_partial_function may produce the wrong answer

find_pc_partial_function may produce the wrong answer

[Paul Koning]

I was tracking down a problem in my (modified) gdb, which showed up
when doing callstack tracing by reading the prologue.  (mips-tdep can
do that, and in my version it does it most of the time.)

The problem is that find_pc_partial_function is used to find the start
of the function, and it was producing the wrong answer.  Specifically,
it produces the wrong answer when the function is in a shared library.

The cause of the problem is that find_pc_partial_function looks up the
symbol in the msymtab, and that contains only external symbols, not
static symbols.  The comments in the source code explicitly claim that
it DOES contain static symbols, but "maint print msymtab" clearly
shows that it doesn't.  At least not for MIPS shared libraries...

I noticed the disassemble command calls the same function, so I
checked why it seemed to be ok.  The difference is that it passes a
pointer to the end_address argument, and that forces the psymtab to be
read which has the right answer.

Well, that's not the whole workaround either.  "disassemble" works
correctly if you just open the shared library ("file
usr/lib/libc.so").  But it too does the wrong thing -- starts
disassembling at the previous non-static function start -- when the
function is in a shared library that's mapped when you open the
corefile, via the "set solib-absolute-prefix" machinery.

Help?

	paul

Re: find_pc_partial_function may produce the wrong answer

[Daniel Jacobowitz]

On Wed, Jul 20, 2005 at 10:28:14AM -0400, Paul Koning wrote:
> I was tracking down a problem in my (modified) gdb, which showed up
> when doing callstack tracing by reading the prologue.  (mips-tdep can
> do that, and in my version it does it most of the time.)
> 
> The problem is that find_pc_partial_function is used to find the start
> of the function, and it was producing the wrong answer.  Specifically,
> it produces the wrong answer when the function is in a shared library.
> 
> The cause of the problem is that find_pc_partial_function looks up the
> symbol in the msymtab, and that contains only external symbols, not
> static symbols.  The comments in the source code explicitly claim that
> it DOES contain static symbols, but "maint print msymtab" clearly
> shows that it doesn't.  At least not for MIPS shared libraries...

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

If for some reason in your modified GDB this is not the case, figure
out why not.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: find_pc_partial_function may produce the wrong answer

[Paul Koning]

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

 Daniel> On Wed, Jul 20, 2005 at 10:28:14AM -0400, Paul Koning wrote:
 >> I was tracking down a problem in my (modified) gdb, which showed
 >> up when doing callstack tracing by reading the prologue.
 >> (mips-tdep can do that, and in my version it does it most of the
 >> time.)
 >> 
 >> The problem is that find_pc_partial_function is used to find the
 >> start of the function, and it was producing the wrong answer.
 >> Specifically, it produces the wrong answer when the function is in
 >> a shared library.
 >> 
 >> The cause of the problem is that find_pc_partial_function looks up
 >> the symbol in the msymtab, and that contains only external
 >> symbols, not static symbols.  The comments in the source code
 >> explicitly claim that it DOES contain static symbols, but "maint
 >> print msymtab" clearly shows that it doesn't.  At least not for
 >> MIPS shared libraries...

 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.

 Daniel> If for some reason in your modified GDB this is not the case,
 Daniel> figure out why not.

It isn't related to the modified gdb; the stock gdb from CVS sources
does the same.

It looks instead like there is something bizarre going on in the
compile.  I looked in the build directory and found that the offending
file (malloc.o) has no static syms in its symbol table according to
readelf.  But when I repeat the compile by hand I get a rather
different looking symbol table that does have them.  Need to track
this down.

Thanks.

	paul

Re: find_pc_partial_function may produce the wrong answer

[H. J. Lu]

On Wed, Jul 20, 2005 at 11:36:48AM -0400, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
> 
>  Daniel> On Wed, Jul 20, 2005 at 10:28:14AM -0400, Paul Koning wrote:
>  >> I was tracking down a problem in my (modified) gdb, which showed
>  >> up when doing callstack tracing by reading the prologue.
>  >> (mips-tdep can do that, and in my version it does it most of the
>  >> time.)
>  >> 
>  >> The problem is that find_pc_partial_function is used to find the
>  >> start of the function, and it was producing the wrong answer.
>  >> Specifically, it produces the wrong answer when the function is in
>  >> a shared library.
>  >> 
>  >> The cause of the problem is that find_pc_partial_function looks up
>  >> the symbol in the msymtab, and that contains only external
>  >> symbols, not static symbols.  The comments in the source code
>  >> explicitly claim that it DOES contain static symbols, but "maint
>  >> print msymtab" clearly shows that it doesn't.  At least not for
>  >> MIPS shared libraries...
> 
>  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.
> 
>  Daniel> If for some reason in your modified GDB this is not the case,
>  Daniel> figure out why not.
> 
> It isn't related to the modified gdb; the stock gdb from CVS sources
> does the same.
> 
> It looks instead like there is something bizarre going on in the
> compile.  I looked in the build directory and found that the offending
> file (malloc.o) has no static syms in its symbol table according to
> readelf.  But when I repeat the compile by hand I get a rather
> different looking symbol table that does have them.  Need to track
> this down.

Are you using gcc 4.0/4.1 by any chance?


H.J.

Re: find_pc_partial_function may produce the wrong answer

[Paul Koning]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

 H> On Wed, Jul 20, 2005 at 11:36:48AM -0400, Paul Koning wrote:
 >> >>>>> "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.

 Daniel> If for some reason in your modified GDB this is not the case,
 Daniel> figure out why not.
 >> It isn't related to the modified gdb; the stock gdb from CVS
 >> sources does the same.
 >> 
 >> It looks instead like there is something bizarre going on in the
 >> compile.  I looked in the build directory and found that the
 >> offending file (malloc.o) has no static syms in its symbol table
 >> according to readelf.  But when I repeat the compile by hand I get
 >> a rather different looking symbol table that does have them.  Need
 >> to track this down.

 H> Are you using gcc 4.0/4.1 by any chance?

No -- gcc 3.3.3 on NetBSD, i386 host, mipsel target.

   paul

Re: find_pc_partial_function may produce the wrong answer

[Paul Koning]

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

Re: find_pc_partial_function may produce the wrong answer

[Daniel Jacobowitz]

On Wed, Jul 20, 2005 at 01:09:03PM -0400, Paul Koning wrote:
> >>>>> "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.

Once you've done that, the fact is, a lot of things in GDB are going to
go wrong.  We assume the presence of minimal symbols in a lot of
places.  However, most of those places it would be an improvement in
GDB to handle only having a function's start represented in the
psymtab.

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

Not really...  There shouldn't be any difference.

-- 
Daniel Jacobowitz
CodeSourcery, LLC