From owner-freebsd-threads@FreeBSD.ORG Fri Jun 20 14:27:15 2003 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 D305C37B401; Fri, 20 Jun 2003 14:27:14 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0607C43FAF; Fri, 20 Jun 2003 14:27:14 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5KLRDDZ078163; Fri, 20 Jun 2003 14:27:13 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5KLRDR8019340; Fri, 20 Jun 2003 14:27:13 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5KLRDCt019339; Fri, 20 Jun 2003 14:27:13 -0700 (PDT) (envelope-from marcel) Date: Fri, 20 Jun 2003 14:27:13 -0700 From: Marcel Moolenaar To: deischen@freebsd.org Message-ID: <20030620212713.GC19212@dhcp01.pn.xcllnt.net> References: <20030620205945.GA19212@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: TLS: defining the problem space 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: Fri, 20 Jun 2003 21:27:15 -0000 On Fri, Jun 20, 2003 at 05:08:16PM -0400, Daniel Eischen wrote: > > > > > > You can have one __tls_get_addr() be a weak definition, and > > > lib{thr,pthread,c_r} can define a non-weak definition. > > > > Of course. The intend of the question was not to ask how, merely to > > ask which. The answer is not simple, because what if we also have a > > (weak) definition in libc to deal with the complete, without pthread > > and dynamic TLS case (if we want to support that)? Then we have 3 > > definitions. > > If both libc and pthread provide weak definitions, then how do we > > guarantee correct binding in the complete, with pthread and dynamic > > TLS case. If libc and RTLD provide weak definitions, then how do we > > guarantee proper binding in the shared, without pthread and dynamic > > TLS case? > > libthr,pthread don't have to supply __tls_get_addr(). They > can tell rtld that they are there and pass in a differently > named function (during rtld_lock_init()). So now you're > back down to two definitions. Does that help? Yes, but it is yet again at the level of the implementation. At the conceptual level there are still 3 different definitions and it's our job to find the implementation that deals with all the cases without ambiguity. Again: we need to keep close to the conceptual level to keep a clear view of things. Once we sink down to the implementation level, things get messy pretty quickly. We need to have something to fall back (up) to if we want to avoid loosing the overview. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net