From owner-freebsd-current Thu Oct 31 9:20:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 386F437B401 for ; Thu, 31 Oct 2002 09:20:16 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97EF943E42 for ; Thu, 31 Oct 2002 09:20:15 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g9VHKELi021820; Thu, 31 Oct 2002 12:20:14 -0500 (EST) Date: Thu, 31 Oct 2002 12:20:14 -0500 (EST) From: Daniel Eischen To: Doug Rabson Cc: ak03@gte.com, tlambert2@mindspring.com, current@freebsd.org Subject: Re: [PATCH: libc]Re: gnome on current In-Reply-To: <20021031161630.Q69202-100000@herring.nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 31 Oct 2002, Doug Rabson wrote: > On Thu, 31 Oct 2002, Daniel Eischen wrote: > > > On Thu, 31 Oct 2002, Doug Rabson wrote: > > > > 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(). > > That was it (I single stepped through this in the debugger a couple of > days ago). Unfortunately init_static_private() also calls > pthread_mutex_init() without the leading underscore. And because it calls the non-underscore version, this breaks something? I guess both init_static_private and init_static should both call _pthread_mutex_init. > > > > > 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? > > I already tried that one this morning. The assignment happens at compile > time unfortunately. What I wanted was for pthread_foo to be resolved in > rtld to the best available _pthread_foo. Unforunately the resolution > happens at link time and by the time we get to rtld, we just have a > pthread_foo which happens to have the same value as _pthread_foo. I wonder how it works for Solaris (you can see both the non-underscore and single-underscore symbols resolve to the same thing)? Perhaps their stubs in libc pull the libgcc trick? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message