Re: __thread errno

[Thomas Schwinge]

Hi!

On Thu, 10 May 2012 17:25:59 +0800, I wrote:
> On Thu, 10 May 2012 03:22:20 +0200, Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > Thomas Schwinge, le Thu 10 May 2012 09:17:33 +0800, a écrit :
> > > On Thu, 10 May 2012 00:10:52 +0000, Samuel Thibault 
> > > <samuel.thibault@ens-lyon.org> wrote:
> > > > commit b7f913cb1bdf9ca718661af315b9f344dc77ebe8
> > > > Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
> > > > Date:   Fri Apr 27 05:42:42 2012 +0200
> > > > 
> > > >     Move errno to TLS
> > > >     
> > > >     * sysdeps/mach/hurd/errno-loc.c: Remove file.
> > > >     * sysdeps/mach/hurd/errno.c: Remove file.
> > > >     * sysdeps/mach/hurd/dl-sysdep.c (errno): Remove variable.

>     $ gdb -q --args ./ld.so 
>     Reading symbols from /home/tschwinge/tmp/ld.so...done.
>     (gdb) r
>     Starting program: /home/tschwinge/tmp/ld.so 
>     
>     Program received signal EXC_BAD_ACCESS, Could not access memory.
>     0x00015797 in __strerror_r (errnum=0, buf=0x0, buflen=2) at 
> dl-minimal.c:173
>     173     dl-minimal.c: No such file or directory.
>             in dl-minimal.c
>     (gdb) bt
>     #0  0x00015797 in __strerror_r (errnum=0, buf=0x0, buflen=2) at 
> dl-minimal.c:173
>     #1  0x00000000 in ?? ()
>     (gdb) info registers
>     eax            0x0      0
>     ecx            0xa      10
>     edx            0x2      2
>     ebx            0x26ff4  159732
>     esp            0x1028c60        0x1028c60
>     ebp            0x1028cb8        0x1028cb8
>     esi            0xa      10
>     edi            0x21b4c  138060
>     eip            0x15797  0x15797 <__strerror_r+167>
>     eflags         0x10202  [ IF RF ]
>     cs             0x17     23
>     ss             0x1f     31
>     ds             0x1f     31
>     es             0x1f     31
>     fs             0x1f     31
>     gs             0x1f     31
> 
> 0x15797 is bogus: it's not even an instruction boundary.
> 
> Apparently I forgot how to debug ld.so from the very beginning...
> 
> It seems that gs is not set up, but even if that were an invalid TLS gs:X
> access, that doesn't explain to me how the PC would be badly affected by
> that?

It appears to me that sysdeps/mach/hurd/dl-sysdep.h bites us:

    /* The private errno doesn't make sense on the Hurd.  errno is always the
       thread-local slot shared with libc, and it matters to share the cell
       with libc because after startup we use libc functions that set errno
       (open, mmap, etc).  */
    
    #define RTLD_PRIVATE_ERRNO 0

And thus in the GNU Hurd configuration, ld.so code uses the __thread
errno -- but TLS has not been set up at this point in ld.so?

In sysdeps/generic/dl-sysdep.h, this is explained/defined as follows:

    /* This macro must be defined to either 0 or 1.
    
       If 1, then an errno global variable hidden in ld.so will work right with
       all the errno-using libc code compiled for ld.so, and there is never a
       need to share the errno location with libc.  This is appropriate only if
       all the libc functions that ld.so uses are called without PLT and always
       get the versions linked into ld.so rather than the libc ones.  */
    
    #ifdef IS_IN_rtld
    # define RTLD_PRIVATE_ERRNO 1
    #else
    # define RTLD_PRIVATE_ERRNO 0
    #endif

Some thought is needed how to solve this errno tangle.

(And I still wonder how this patch can be working in any of your glibc
trees?)


> In sysdeps/unix/sysv/linux/bits/errno.h, the »#define errno
> (*__errno_location ())« is conditioned by »#if !defined _LIBC || defined
> _LIBC_REENTRANT« -- should we be doing that, too?

sysdeps/mach/hurd/configure.in:

    # GNU libc on the Hurd is always reentrant.
    DEFINES="$DEFINES -D_LIBC_REENTRANT"

That probably also holds for every sensible GNU/Linux configuration (via
sysdeps/pthread/configure); I'll add a TODO item to my ever-growing list,
to confirm that and get rid of the !_LIBC_REENTRANT case.


Grüße,
 Thomas

pgpjgnCpV3xrU.pgp
Description: PGP signature