Re: find_pc_partial_function may produce the wrong answer

[Daniel Jacobowitz <drow at false dot org>]

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