Date: Thu, 31 Oct 2002 11:07:06 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Doug Rabson <dfr@nlsystems.com> Cc: ak03@gte.com, tlambert2@mindspring.com, current@freebsd.org Subject: Re: [PATCH: libc]Re: gnome on current Message-ID: <Pine.GSO.4.10.10210311101540.11490-100000@pcnet1.pcnet.com> In-Reply-To: <20021031154052.L69202-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 2002, Doug Rabson wrote: > On Thu, 31 Oct 2002, Daniel Eischen wrote: > > > On Thu, 31 Oct 2002, Doug Rabson wrote: > > > On Thu, 31 Oct 2002, Daniel Eischen wrote: > > > > You can also play the libgcc game inside of libc for those applications > > > > or libraries that are too lazy to do it for themselves. Have the > > > > libc pthread stubs key on a weak reference to pthread_create and > > > > call the pthread_* if they are present. libXThrStub should be > > > > able to do that though. > > > > > > It almost doesn't matter which of the solutions we use as long as we do > > > something. What we currently have is clearly wrong but I'll list it along > > > with the others. Solutions so far proposed are: > > > > > > 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads > > > implementation defines strong _pthread_* symbols and weak pthread_* > > > aliases for them. Anyone else which defines pthread_* symbols (either weak > > > or strong) can take over and will normally end up breaking libc. > > > > We only use _pthread_* in libc, so it doesn't break libc unless > > they provide strong symbols for _pthread_*. Our implementation > > relies on the use of single underscore versions in libc so we > > can tell the difference between the implementation locks and > > application locks. The weak references from pthread_* in libc_r > > are to the double underscore versions (mostly, the locking > > functions) so that applications actually resolve to __pthread_mutex_lock > > and libc uses will resolve to _pthread_mutex_lock. > > Actually its pretty easy to break libc. Someone calls flockfile() which in > turn calls _pthread_mutex_lock(). This ends up in libc_r which notices > that the mutex is uninitialised and calls init_static(). That calls > pthread_mutex_init() and dies shortly afterwards (note the non-_pthread > call from init_static()). I don't see how that can be. _pthread_mutex_lock() in libc_r calls init_static_private(), not init_static(). > > > > > > Right now, I can't tell what Solaris does. Alexander suggested that it was > > > (1) but you disagree. It would be interesting to see the output of 'nm | > > > grep pthread' for both libc.so and libpthread.so. > > > > I've already done that and posted it. Here it is again. > > > > ... > > Ok then. Next attempt. This one defines weak pthread_foo stubs which call > _pthread_foo. It also defines weak _pthread_foo stubs which are noops. All > symbols weak. Everyone happy. Actually, I haven't tested this since my > test system is at home. For kicks, I also staticised the stubs. This is better, although it has two stubs for each routine. Adding a weak definition from pthread_foo() to _pthread_foo() (note the lack of _stub) doesn't do the same thing? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10210311101540.11490-100000>