This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/20680] New: ifunc resolver cannot access the thread pointer with static linking
- From: "nszabolcs at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 10 Oct 2016 17:19:33 +0000
- Subject: [Bug libc/20680] New: ifunc resolver cannot access the thread pointer with static linking
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=20680
Bug ID: 20680
Summary: ifunc resolver cannot access the thread pointer with
static linking
Product: glibc
Version: 2.24
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: nszabolcs at gmail dot com
CC: drepper.fsp at gmail dot com
Target Milestone: ---
the thread pointer is not yet initialized when ifunc resolvers are
run with static linking.
this means -fstack-protect-all instrumented resolver crashes with
static linking on targets where the canary is in tcb.
(can affect any tcb offset abi the compiler may use, like the
hwcap/platform on powerpc.)
and any tls access crashes the resolver (accessing errno or using
tls with global dynamic model can crash with dynamic linking too
because they are extern calls, see bug 20673).
it is generally not documented what c code may work before
thread-pointer setup.
compile with -static
$ cat main.c
static int foo1(void) { return 1; }
static int foo2(void) { return 2; }
__thread int x; // or try -fstack-protect-all
static int (*foo_resolver())()
{
return x ? foo1 : foo2;
}
int foo(void) __attribute__((ifunc("foo_resolver")));
int main()
{
foo();
}
--
You are receiving this mail because:
You are on the CC list for the bug.