[Bug libc/17319] New: init_tls switches around esp during set_thread_area syscall

["mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17319

            Bug ID: 17319
           Summary: init_tls switches around esp during set_thread_area
                    syscall
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: mjw at redhat dot com
                CC: drepper.fsp at gmail dot com

Originally reported and analysed at
https://bugzilla.redhat.com/show_bug.cgi?id=1133134

TLS_INIT_TP in sysdeps/i386/nptl/tls.h uses some hand written asm to generate a
set_thread_area syscall that might result in exchanging ebx and esp around the
syscall causing introspection tools like valgrind to loose track of the user
stack.

The TLS_INIT_TP macro contains:

     /* Install the TLS.  */                                                  \
     asm volatile (TLS_LOAD_EBX                                               \
                   "int $0x80\n\t"                                            \
                   TLS_LOAD_EBX                                               \
                   : "=a" (_result), "=m" (_segdescr.desc.entry_number)       \
                   : "0" (__NR_set_thread_area),                              \
                     TLS_EBX_ARG (&_segdescr.desc), "m" (_segdescr.desc));    \

Which gets turned into:

   0x04000a1c <+274>: mov    $0xf3,%eax
   0x04000a21 <+279>: movl   $0xfffff,0x8(%esp)
   0x04000a29 <+287>: movl   $0x51,0xc(%esp)
=> 0x04000a31 <+295>: xchg   %esp,%ebx
   0x04000a33 <+297>: int    $0x80
   0x04000a35 <+299>: xchg   %esp,%ebx
   0x04000a37 <+301>: test   %eax,%eax
   0x04000a39 <+303>: jne    0x4000a52 <init_tls+328>

That will cause valgrind errors like:

==10806== Warning: client switching stacks?  SP change: 0xfec25590 -->
0x4024f94
==10806==          to suppress, use: --max-stackframe=88078852 or greater
==10806== Warning: client switching stacks?  SP change: 0x4024f94 -->
0xfec25590
==10806==          to suppress, use: --max-stackframe=88078852 or greater

Thanks to Florian Weimer for analysing why the original code generated
the bogus esp usage:

  _segdescr.desc happens to be at the top of the stack, so its address
  is in %esp.  The asm statement says that %3 is an input, so its value
  will not change, and GCC can use %esp as the input register for the
  expression &_segdescr.desc.  But the constraints do not fully describe
  the asm statement because the %3 register is actually modified, albeit
  only temporarily.

-- 
You are receiving this mail because:
You are on the CC list for the bug.