From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30150 invoked by alias); 22 Jun 2002 01:10:47 -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 30114 invoked from network); 22 Jun 2002 01:10:45 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 22 Jun 2002 01:10:45 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 15A445EA11; Fri, 21 Jun 2002 20:10:43 -0500 (EST) To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020619160004.38A625EA11@zwingli.cygnus.com> <3D1282DD.7000508@cygnus.com> From: Jim Blandy Date: Fri, 21 Jun 2002 18:10:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-06/txt/msg00188.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. 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. Given that hpread.c hard-codes a reference to the macro CR27_REGNUM, which is only defined in config/pa/tm-hppa.h, I assume that hpread.c is only used in PA targets. The PA hasn't been multi-arched, so I assume it's going away. So, does anyone care if I break the hpread.c code?