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