more symbol binding problems
sean at mcneil.com
Mon Jun 7 17:02:59 GMT 2004
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
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.
More information about the freebsd-amd64