Re: debugging a dynamically loaded library

["H . J . Lu" <hjl@lucon.org>]

On Wed, Sep 05, 2001 at 11:04:03PM -0700, Kevin Buettner wrote:
> On Sep 5, 10:29pm, H . J . Lu wrote:
> 
> > I am wondering if
> > 
> > 1327   FUN    0      36     00000000 31372  __strtol_internal:F(0,3)
> > 
> > is a valid stab entry. It it is valid, why does it trigger the
> > SOFUN_ADDRESS_MAYBE_MISSING code in gdb. Is that possible a linker
> > or assembler bug?
> 
> It's always possible that there's a bug elsewhere, but my guess is
> that __strtol_internal() is merely the first function in the section
> in which case the above entry makes sense to me.

No. That is not the case. In glibc 2.2, which is used in RedHat 7.1,
__strtol_internal is a weak definition in the object files used to
build libdl.so.2:

# objdump --sym eval.os | grep __strtol_internal
00000440  w    F .text  00000137 __strtol_internal

But when libdl.so.2 is generated against libc.so.6:

# objdump --sym ../libc.so.6 | grep __strtol_internal
00032d04 g     F .text  000006ab              __strtol_internal

the linker generates

# objdump --sym libdl.so.2 | grep __strtol_internal
00000000  w    F *UND*  000006ab              __strtol_internal@@GLIBC_2.0

in libdl.so.2. I am 100% sure where the bug is. It can be in as, ld,
gcc and/or gdb. I tend to think it is a linker bug since the intention
of glibc is to make __strtol_internal weak defined, not weak undefined.
My second thought a weak undefined __strtol_internal in this case may
be the right thing to do, given how weak should be treated. Now the
question is how as/ld/gcc/gdb should deal a symbol which is turned from
weak defined to weak undefined. Does stabs/gdb support the notation of
weak defined symbol, which may be changed between compile-time,
link-time and run-time?

As for how useful a weak defined __strtol_internal is in libdl.so, that
is an entirely different question.


H.J.