From owner-freebsd-threads@FreeBSD.ORG Mon Jun 7 17:02: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 6554916A4CE; Mon, 7 Jun 2004 17:02:59 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2677343D58; Mon, 7 Jun 2004 17:02:59 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CF4EAFD03B; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09857-06; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0F114FD020; Mon, 7 Jun 2004 10:02:58 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086627777.39706.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 10:02:57 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com 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 17:02:59 -0000 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.