errno definition broken in non-threaded code

[Mike Frysinger]

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

> I suspect the difference in code size between location functions and
> GOT references is minimal, and because I doubt the speed has any
> impact on real applications.  If those suspicions are right, why not
> have ABI compatibility?

i'm really not worried about the size of the GOT ... if errno is accessed 
directly, you save on all the function calls/indirect references
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20070221/9ebe0df8/attachment-0002.pgp