Date: Mon, 7 Jun 2004 12:50:59 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems Message-ID: <Pine.GSO.4.10.10406071245010.24569-100000@pcnet5.pcnet.com> In-Reply-To: <1086625305.10454.33.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406071245010.24569-100000>