debugging a dynamically loaded library
H . J . Lu
hjl@lucon.org
Thu Sep 6 10:25:00 GMT 2001
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.
More information about the Libc-alpha
mailing list