From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 16:50:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED67D16A4CE; Mon, 7 Jun 2004 16:50:59 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A742C43D1F; Mon, 7 Jun 2004 16:50:59 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i57GoxtD000256; Mon, 7 Jun 2004 12:50:59 -0400 (EDT) Date: Mon, 7 Jun 2004 12:50:59 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086625305.10454.33.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:51:00 -0000 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. -- Dan Eischen