Date: Mon, 07 Jun 2004 10:02:57 -0700 From: Sean McNeil <sean@mcneil.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems Message-ID: <1086627777.39706.12.camel@server.mcneil.com> In-Reply-To: <Pine.GSO.4.10.10406071245010.24569-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10406071245010.24569-100000@pcnet5.pcnet.com>
index | next in thread | previous in thread | raw e-mail
On Mon, 2004-06-07 at 09:50, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: > > > On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote: > > > > > > It doesn't work here and I don't believe ever has since libc_r > > > was split from libc. > > > > Many years ago, I was involved with pthreads for Linux. I helped them > > get things straight using the weak reference trick. I don't remember > > where I picked it up from, but I it was real slick how they were used to > > override functions in libc by having stronger references in the > > threading lib. libc_r and folks don't use this trick anymore? Odd. > > > > But the questions for today: > > > > Say you have an application that depends on libraries A, B, C, and > > libc. It then uses dlopen to load D. D depends on E, F, libpthread, > > and B. Is B considered to be in D's DAG? > > > > If so, then when a function within B calls a function that hasn't been > > bound yet in libpthread then it should bind to the threaded version. > > There are good arguments either way. IMHO, rtld is acting as though the > > answer is no and I want it to behave as yes. > > I don't know what a DAG is, but I believe I've already explained > the problem. We don't litter our thread libraries with strong > references for every thread interface. You must make sure > references are resolved correctly by linking ordering. > > > There is strong evidence to support this. The libreadline trace from > > bash and the php4 trace from httpd both only make sense if the lazy > > symbol resolver is not ending up with the threaded version of some call > > (sigaction and select respectively). > > > > Second, to save me some time can someone outline the symbol name > > mechanism used by libpthread? Here is what I expect: > > > > libc provides a sigaction function through a weak reference that points > > to some internal name (like __sigaction). libpthread provides a strong > > reference to sigaction thus, when loaded, overrides usage of sigaction. > > This should happen irregardless of whether libpthread is in the DAG for > > the caller (IMHO), but I'm sure there are other opinions. > > There are no strong references (other than a handful that are > needed by rtld). We mandate that you link things in the proper > order. Then I submit to you that signals are broken in KSE/libpthread at the very least. libpthread makes the assumption that it will take over principle control of sigaction and friends. So, if I link with "-lc -lpthread" I should use the versions in libc and it should work. If I link with "-lpthread -lc" then I should use the versions in libpthread. Yet constructors for libpthread will install hooks for signals that undermines the proper behavior of the original sigaction function. I also submit to you that FreeBSD is not behaving like any other UNIX implementation that I have worked with if this is the case. pthread functions should have precedence over their libc counterparts regardless of link order.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086627777.39706.12.camel>