more symbol binding problems

[Sean McNeil]

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.