|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 5:15:12 pm|
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.