This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17319] New: init_tls switches around esp during set_thread_area syscall
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 27 Aug 2014 15:01:48 +0000
- Subject: [Bug libc/17319] New: init_tls switches around esp during set_thread_area syscall
- Auto-submitted: auto-generated
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.