errno definition broken in non-threaded code

Jim Blandy jimb at codesourcery.com
Mon Sep 25 19:35:50 UTC 2006


Mike Frysinger <vapier at gentoo.org> writes:
> On Saturday 23 September 2006 02:02, Jim Blandy wrote:
>> I'm beginning to think libc_hidden_proto and libc_hidden_def can't be
>> used for errno in non-threaded configurations, without a change to the
>> way errno is defined for user code.  Trunk revision r13360 may not be
>> quite right.
>
> user code should not be accessing errno directly ... that is the point of the 
> __errno_location() function ...

I see --- so uClibc should not be exporting errno as a plain variable,
as it does now.

>> On the trunk, configured with no thread support, I'm seeing a number
>> of test failures related to errno not being set properly.  For
>> instance, test/inet/bug-if1.c fails, saying that errno is zero instead
>> of the expected value, ENXIO.  (My target is ARM Linux, but as far as
>> I can see that shouldn't matter.)
>
> the target arch does matter ... if you look at the binutils list, there's a 
> thread about handling hidden references to data and how on some architectures 
> it works while on others it def does not work ... and it all comes down to 
> relocations

I'm told MIPS requires all global variable references to go via GOT
entries, so the dynamic linker can point the executable at the
library's copy of the variable; problem solved.  But pretty much all
other architectures do use copy relocs, which allows the main
executable to use faster code for its own global variable references.

> the arches that fail utilize copy relocs and thus each relocated section gets 
> its own copy of the data
>
> personally i still think this is a bug in binutils, but Alan Modra says it 
> isnt and i certainly dont have enough technical knowledge to take him on

Well, using libc_hidden_proto/libc_hidden_def, you've got the
library's code accessing errno via pc-relative addressing, and (on
non-MIPS platforms) you've got the main executable accessing errno at
a fixed address.  They can't both be right.  The linker can't solve
the problem, because you need different instruction sequences to make
either of them use a GOT.  I'm not sure what binutils would do.



More information about the uClibc mailing list