Date: Tue, 24 Nov 2020 04:57:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 251112] Compiling C++ with asan fails by default because libclang_rt.asan-x86_64.so uses symbol pthread_attr_get_np but doesn't link to libpthread.so Message-ID: <bug-251112-227-x6XPRUOAtJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251112-227@https.bugs.freebsd.org/bugzilla/> References: <bug-251112-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251112 --- Comment #9 from Andrew Stitcher <astitcher@apache.org> --- (In reply to Konstantin Belousov from comment #8) I think I understand the libpthread/libc interaction a bit better now: It s= eems that the only way to get pthread_create() is to actually link libpthread. So any executable that actually has multiple threads will necessarily have libpthread linked in. This is what I was missing before when you were talki= ng about pthread stubs - that is no stub for pthread_create() in libc. It looks like there are stubs (weak symbols) in libc for the other relevant pthread symbols used in libclang_rt.asan (even the ones that are documented= to require linking with -lpthread) so I think it would make sense to have a st= ub for pthread_attr_get_np() which returns the ESRCH error (this is the docume= nted return if it cannot find the thread id which I think is necessarily the cas= e if there are no threads!). In the case of libclang_rt.asan I think if it did g= et called somehow - which looks to be impossible - the return value is checked= and should abort the run. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251112-227-x6XPRUOAtJ>