errno definition broken in non-threaded code
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
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