[Top] [All Lists]

Re: uclibc mips and undefined symbols with nonzero symbol table en

To: "Bradley D. LaRonde" <>
Subject: Re: uclibc mips and undefined symbols with nonzero symbol table entry st_value
From: Richard Sandiford <>
Date: Mon, 10 May 2004 08:40:37 +0100
Cc: <>, <>
In-reply-to: <012701c43607$83aa65f0$8d01010a@prefect> (Bradley D. LaRonde's message of "Sun, 9 May 2004 16:52:17 -0400")
Original-recipient: rfc822;
References: <045b01c43155$1e06cd80$8d01010a@prefect> <> <012701c43607$83aa65f0$8d01010a@prefect>
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux)
"Bradley D. LaRonde" <> writes:
>> An object should never use stubs if takes the address of the function.
>> It should only use a stub for some symbol foo if every use of foo is
>> for a direct call.
> OK.  So in a case where an object does take a pointer, does that mean that
> must fix the GOT entry for that symbol before handing control to the
> app (i.e. no lazy binding for that symbol)?

Right.  Such objects won't use a stub, they'll just have a normal
reference to an undefined symbol.  The dynamic loader must resolve
it in the usual way.

> I notice that the debian mipsel in
> has
> st_value == 0 for every UND FUNC, just like my x86 debian libraries.  This
> is very different than the uClibc where every UND FUNC has
> st_value != 0.  Interestingly if I link glibc's libpthread with uClibc's
> I see that most UND FUNCs then have st_value != 0.

You said in your original message that you'd recently upgraded to binutils
2.15-based tools.  Was your built with them?  If so, that would
explain it.  I think earlier versions of ld were overly pessimistic about when
stubs could be used.

FWIW, I have a glibc-based sysroot built with gcc 3.4 and binutils 2.15.
Its libpthread uses plenty of stubs.


<Prev in Thread] Current Thread [Next in Thread>