more symbol binding problems

[Sean McNeil]

On Mon, 2004-06-07 at 06:25, Daniel Eischen wrote:
> On Mon, 7 Jun 2004, Sean McNeil wrote:
> 
> > On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote:
> > > 
> > > It doesn't work under i386 either.  Remember the nss_ldap
> > > problem?  That was exactly the same and on i386.
> > 
> > There is no nss_ldap problem.  nss_ldap worked perfectly on i386.  It
> > causes issues on amd64 because of a problem in threads.
> 
> Yes, there was.  See the archives (I forget if it was -current
> or -threads).  I believe the resolver functions in libc were
> changed to work around it.

If you are talking about nsdispatch, then I am very intimate with the
issue as I found and fixed the problem.  It has to do with when an
application finally shuts down.  That is when it unloaded the library.

> > > > Let me make reiterate....  I am using a system that I converted from
> > > > i386 to amd64.  Everything (all the ports) were working without any
> > > > problems whatsoever.  These are the same exact ports that I convert over
> > > > to amd64.  If it is not legal to do things like this then why do these
> > > > exact same ports work perfectly fine with freebsd/i386?
> > > > 
> > > > Your analysis and assistance with this has been invaluable so far, but I
> > > > don't want this to just be dismissed because in principle it doesn't
> > > > need to be supported.  IMHO, amd64 should work just like i386.  Since it
> > > > works with i386, shouldn't we make it work for amd64?
> > > 
> > > There is no difference.  It isn't going to work on i386 either.
> > > Once you load the threads library, the libc locking functions
> > > will be overloaded with the locking functions in libpthread.
> > > When libpthread is unloaded, libc locking functions still point
> > > to the now non-existent library.  If something tries to use
> > > a lock, fall down go boom.
> > 
> > It worked on i386.  None of the cases mentioned before unload the thread
> > library until an atexit.
> 
> I thought they were automatically unloaded when the library
> was unloaded.  That was the problem with nss_ldap.

During the life of any application, it usually loads extensions but
doesn't unload them unless shutting down.  bash was never unloading the
nss_ldap, httpd was never unloading php4.  This is not the issue
(load/unload).

> > > There's also the problem of overloaded functions and cancellation
> > > points.  These won't work correctly because of ordering.  It's
> > > like trying to use '-lc -lpthread' to link an application.
> > > That isn't going to work; you need '-lpthread -lc'.
> > 
> > As far as I know, this works.  At least for Linux and it should for
> > FreeBSD.  The ordering doesn't matter because the overloaded routines
> > are actually weak references in libc and strong references in pthread. 
> > So pthread symbols win.
> 
> 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.

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.