errno definition broken in non-threaded code

[Jim Blandy]

Mike Frysinger <vapier at gentoo.org> writes:
> On Friday 17 November 2006, Jim Blandy wrote:
>> Mike Frysinger <vapier at gentoo.org> writes:
>> > so, would the correct fix here be:
>> >  - if thread support is disabled, export errno symbols and do not define
>> > the location functions at all requiring all internal uClibc references to
>> > go through the GOT to get at the errno location
>> >  - if thread support is enabled, do not export the errno symbols and
>> > allow internal hidden references to it from the location functions
>>
>> I've gone fuzzy on the details, but I think my favorite would be:
>>
>> - If thread support is disabled and libc is statically linked, export
>>   errno symbols.  (I thought I saw assembly code somewhere calling the
>>   location functions, so maybe they can't go, but that's fuzzy now
>>   too.)
>>
>> - Otherwise, keep errno hidden and have all external accesses go via
>>   location functions.
>
> should be fixed in svn now ... if thread support is enabled, then the 
> symbols "errno" and "h_errno" do not exist and must be accessed via the 
> macro/location functions ... the internal errno/h_errno have hidden defs to 
> avoid relocs
>
> if thread support is disabled, then the errno and h_errno symbols are exported 
> and the hidden defs do not exist
>
> i think this should fix things up eh

Sounds like it.

If we try to use hidden defs and global aliases for exported
variables, then the problem is that the public symbol's address gets
set by the dynamic linker, while the libc-private symbol's address is
fixed (relative to libc's load address) at static link time, leaving
libc and user code accessing different variables.

But now we never use hidden defs for errno or h_errno in any
circumstances, so all is well.

If I'm understanding what you've said right, in the dynamic,
non-threaded case, libc itself will be going through the GOT to find
errno and h_errno, as will user code.  If it were up to me, I'd have
user code go through accessor functions and libc access directly in
all but the static non-threaded case.  But that's really a question of
taste; things are correct either way.