From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15146 invoked by alias); 22 Jun 2002 03:24:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15138 invoked from network); 22 Jun 2002 03:24:27 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Jun 2002 03:24:27 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D02283D72; Fri, 21 Jun 2002 23:24:26 -0400 (EDT) Message-ID: <3D13EDEA.2070801@cygnus.com> Date: Fri, 21 Jun 2002 20:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020619160004.38A625EA11@zwingli.cygnus.com> <3D1282DD.7000508@cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00193.txt.bz2 > Jim Blandy writes: > >> Andrew Cagney writes: > >> > Has solaris, or even MS, done anything in this area? The >> > LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you >> > may want to look at what HP/UX is getting up to. > >> HP implements something much simpler. It doesn't deal with >> thread-local storage in PIC code; the initialization image is laid out >> completely at static link time. It's thread-local storage in >> dynamically loaded libraries that introduces all the hair. > > > What I wrote is incorrect. HP does handle TLS in shared libraries. > But in their arrangement, every thread-local variable lives at a > offset from register CR27, and GDB can compute that offset at > symbol-reading time. > > I think this means that they don't address a lot of the issues that > the IA-64 / SPARC / Red Hat proposal does. I don't see how you'd > handle dlopen'd libraries or lazy allocation in their scheme. I don't know. HP people do monitor this list so may be able to answer. > But in any case, HP's gdbarch method for finding thread-local storage > would be very simple: just add the offset to CR27, and there's your > address. BTW, why, in your propsal, is the offset incorporated into the address that is returned - rather than getting the base address and then adding the offset - more like HP did. Andrew