[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