|Sean McNeil||Jun 6, 2004 4:28 pm|
|Daniel Eischen||Jun 6, 2004 5:25 pm|
|Sean McNeil||Jun 6, 2004 5:43 pm|
|Daniel Eischen||Jun 7, 2004 3:52 am|
|Daniel Eischen||Jun 7, 2004 3:56 am|
|Sean McNeil||Jun 7, 2004 4:06 am|
|Daniel Eischen||Jun 7, 2004 4:37 am|
|Sean McNeil||Jun 7, 2004 4:59 am|
|Daniel Eischen||Jun 7, 2004 5:30 am|
|Sean McNeil||Jun 7, 2004 10:18 am|
|Daniel Eischen||Jun 7, 2004 1:25 pm|
|Sean McNeil||Jun 7, 2004 4:30 pm|
|Daniel Eischen||Jun 7, 2004 5:00 pm|
|Sean McNeil||Jun 7, 2004 5:15 pm|
|Subject:||more symbol binding problems|
|From:||Sean McNeil (se...@mcneil.com)|
|Date:||Jun 7, 2004 4:30:27 pm|
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.