From owner-freebsd-threads@freebsd.org Sat Jul 27 11:51:42 2019 Return-Path: Delivered-To: freebsd-threads@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 33B82B71DD for ; Sat, 27 Jul 2019 11:51:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 17A4B77E6C for ; Sat, 27 Jul 2019 11:51:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 151DBB71DC; Sat, 27 Jul 2019 11:51:42 +0000 (UTC) Delivered-To: threads@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 14E2AB71DB for ; Sat, 27 Jul 2019 11:51:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E975977E69 for ; Sat, 27 Jul 2019 11:51:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DA11C26D2D for ; Sat, 27 Jul 2019 11:51:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6RBpfL7001435 for ; Sat, 27 Jul 2019 11:51:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6RBpfCL001434 for threads@FreeBSD.org; Sat, 27 Jul 2019 11:51:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 239475] Linking libthr with -nodefaultlibs statically can cause infinite recursion Date: Sat, 27 Jul 2019 11:51:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: arichardson@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: E975977E69 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 11:51:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239475 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@FreeBSD.org Reporter: arichardson@FreeBSD.org For the following test program: ``` #include #include int main() { printf("pthread_create =3D %p\n", (void*)&pthread_create); return 0; } ``` If I link -lthr after -lc, I get infinite recursion in the pthread interpos= ing table since the value in libthr.a is resolved to the one from libc which th= en 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=3D= lld && ./test-c-first Whereas this works: clang -static -o test-thr-first -nodefaultlibs -lthr -lc test.c -fuse-ld=3D= lld && ./test-thr-first pthread_create =3D 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 sh= ould not happen even if you link in the wrong order. I'm not sure why the functi= ons in the libthr table resolve to the libc ones instead of the ones in libthr. --=20 You are receiving this mail because: You are the assignee for the bug.=