Problem with __GI_errno_location and _h__errno_location alias names

Johannes Stezenbach js at sig21.net
Thu Jan 19 12:34:40 UTC 2012


On Thu, Jan 19, 2012 at 10:20:12AM +0100, stl wrote:
> I am porting Linux for a new architecture, and I chose to build a
> cross compiler link against uClibc in order to build my linux system.

Do you mean architecture as in ARM, MIPS, etc. or just new board?

> I have ported uClibc-0.9.31 (I have not done anything dealing with
> shared libs yet).
> I have finally succeeded in building a static hello world executable
> (that is running on
> my port of uClinux-2.6.19 at the moment).

If you're doing a new port, why do you use an ancient kernel?
And why an old uClibc?

> But I am facing a problem,  the execution stop with a SIGILL due to the
> following undefined symbols: __errno_location()  and  __h_errno_location()
> 
> I have seen that most of symbols are compiles under an alias name __GI_foo (),
> and appear in the objdump -t output twice: foo and __GI_foo
> 
> An objdump of __errno_location.o and __h_errno_location.o shows that these
>  symbols are compiled under __GI__ alias names.
> 
> Here is a objdump part of my hello_world exe:
> 
> 00000000  w      *UND*	00000000 __h_errno_location
> 00000000  w      *UND*	00000000 __errno_location

>From the nm man page:

	   "w" The symbol is a weak symbol that has not been specifically
	       tagged as a weak object symbol.  When a weak defined symbol is
	       linked with a normal defined symbol, the normal defined symbol
	       is used with no error.  When a weak undefined symbol is linked
	       and the symbol is not defined, the value of the symbol is
	       determined in a system-specific manner without error.  On some
	       systems, uppercase indicates that a default value has been
	       specified.

> The function __uClibc_main() seems to expect these 2 function under
> their normal name,
> but there are compiled under alias name..
> 
> My first (trivial) question is: What does mean GI?

I'm guessing it means something like "glibc internal".  It is used
in shared libs to bypass PLT lookup as an optimization.  You can
read about that in Ulrich Drepper's dsohowto.pdf.
http://www.akkadia.org/drepper/
For static libs the __GI__ aliases are not useful (if my understanding
is correct), but they shouldn't cause harm.

> Alias seem to work correcly with other symbols..
> Is there something special for __errno_location()  and  __h_errno_location()?
> Why the cross-compiler doesn't complain about missing __errno_location
> and _h_errno_location
> symbols during compilation?

libpthread must be able to override these (since errno is per thread, TLS),
so the symbols are weak.  It looks like your libc does not define these symbols?

For my current uClibc for ARM it looks like this:

$ arm-linux-nm libc.a | less
...
__errno_location.o:
00000000 T __GI___errno_location
         U __aeabi_read_tp
00000000 W __errno_location
         U __libc_errno

__h_errno_location.o:
00000000 W __GI___h_errno_location
         U __aeabi_read_tp
00000000 W __h_errno_location
         U __libc_h_errno

(I'm not sure why __GI___errno_location is not weak but since
__syscall_error uses __libc_errno it does not seem to matter.)


HTH
Johannes


More information about the uClibc mailing list