[Bug 239475] Linking libthr with -nodefaultlibs statically can cause infinite recursion
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sat Jul 27 11:51:42 UTC 2019
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239475
Bug ID: 239475
Summary: Linking libthr with -nodefaultlibs statically can
cause infinite recursion
Product: Base System
Version: 11.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: threads
Assignee: threads at FreeBSD.org
Reporter: arichardson at FreeBSD.org
For the following test program:
```
#include <stdio.h>
#include <pthread.h>
int main() {
printf("pthread_create = %p\n", (void*)&pthread_create);
return 0;
}
```
If I link -lthr after -lc, I get infinite recursion in the pthread interposing
table since the value in libthr.a is resolved to the one from libc which then
just calls itself.
#0 0x000000000026c0bc in __pthread_cleanup_push_imp ()
#1 0x000000000026c30a in printf ()
#2 0x000000000026c25d in main ()
The following fails:
$ clang -static -o test-c-first -nodefaultlibs -lc -lthr test.c -fuse-ld=lld &&
./test-c-first
Whereas this works:
clang -static -o test-thr-first -nodefaultlibs -lthr -lc test.c -fuse-ld=lld &&
./test-thr-first
pthread_create = 0x24dbc0
I am hitting this issue while writing some tests that want to avoid pulling in
all default libs, but the order if libraries on the link command line is
difficult to change.
I can probably work around it, but it seems like this infinite recursion should
not happen even if you link in the wrong order. I'm not sure why the functions
in the libthr table resolve to the libc ones instead of the ones in libthr.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-threads
mailing list