From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15612 invoked by alias); 2 Oct 2002 15:29:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15591 invoked from network); 2 Oct 2002 15:29:27 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Oct 2002 15:29:27 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g92FAai17000 for ; Wed, 2 Oct 2002 11:10:36 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g92FTQf10810 for ; Wed, 2 Oct 2002 11:29:26 -0400 Received: from localhost.redhat.com (IDENT:root@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g92FTP906446 for ; Wed, 2 Oct 2002 11:29:25 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 832C4FF79; Wed, 2 Oct 2002 11:27:03 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15771.4167.376619.979350@localhost.redhat.com> Date: Wed, 02 Oct 2002 08:29:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] TLS support part 2 In-Reply-To: <20021002145730.GB22578@nevyn.them.org> References: <15770.63097.522572.688579@localhost.redhat.com> <20021002145730.GB22578@nevyn.them.org> X-SW-Source: 2002-10/txt/msg00052.txt.bz2 Daniel Jacobowitz writes: > On Wed, Oct 02, 2002 at 09:36:57AM -0400, Elena Zannoni wrote: > > > > Here is the thread/target related part of the TLS support. > > > > A new thread layer op has been added, to fetch the address of the variable. > > OK, I see how it works now. This is workable for gdbserver; I'll just > have to figure out how to ask for the link map address in some portable > way. This will take some thinking; the best way to do it involves > noticeable protocol changes... > Yeah, that's the part that gave me the most hard time. I am not sure that it really belongs in solib-svr4.c, but it is the "best" place I could think of putting it in. Elena > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer