From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12321 invoked by alias); 16 Nov 2004 02:06:27 -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 11622 invoked from network); 16 Nov 2004 02:06:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 Nov 2004 02:06:20 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAG26EMg022836 for ; Mon, 15 Nov 2004 21:06:19 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAG26Er07030; Mon, 15 Nov 2004 21:06:14 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 804B9129D8C; Mon, 15 Nov 2004 21:06:05 -0500 (EST) Message-ID: <4199608B.2020108@gnu.org> Date: Tue, 16 Nov 2004 02:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: Proposal: qGetTLSAddr remote protocol packet References: <20041105154438.7676aa13@saguaro> In-Reply-To: <20041105154438.7676aa13@saguaro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00153.txt.bz2 Kevin Buettner wrote: > Below is a proposal for a new remote protocol packet for fetching a > thread local storage address. It is written it in a form (sans markup) > that is compatible with the rest of the remote protocol documentation. > > Comments / suggestions? > > ------------------- > > qGetTLSAddr:thread-id:offset:other-param1:other-param2:...:other-paramN > -- get thread local storage address @var{query} may optionally be followed by a @samp{,} or @samp{;} separated list. Stubs must ensure that they match the full @var{query} name. > Fetch the address associated with thread local storage specified > by thread-id, offset, and other-param1 thru other-paramN. > > thread-id is the (big endian, hex encoded) thread id associated with the > thread for which to fetch the TLS address. > > offset is the (big endian, hex encoded) offset associated with the > thread local variable. (This offset is obtained from the debug > information associated with the variable.) > > other-param1 .. other-paramN are (big endian, hex encoded) OS/ABI > specific data required for fetching the TLS address. For example, a > GNU/Linux system will pass (as other-param1) the link map address of > the shared object associated with the thread local storage under > consideration. Other operating environments may require different > data, so the precise meaning of these fields will vary. That's different to: /* Return the thread-local address at OFFSET in the thread-local storage for the thread PTID and the shared library or executable file given by OBJFILE. If that block of thread-local storage hasn't been allocated yet, this function may return an error. */ CORE_ADDR (*to_get_thread_local_address) (ptid_t ptid, struct objfile *objfile, CORE_ADDR offset); The two should be consistent - remote.c being a thin vineer. Is there a sample implementation involving gdbserver? > XX... > Hex encoded (big endian) bytes representing the address of the thread > local storage requested. I'm wondering how usefful the error codes are. Even after turning all that information, all that gets printed is: if (err != TD_OK) { if (objfile_is_library) error ("Cannot find thread-local storage for thread %ld, " "shared library %s:\n%s", (long) GET_THREAD (ptid), objfile->name, thread_db_err_str (err)); where thread_db_err_str() is a string, and experience tells us that even will all the choices: typedef enum { PS_OK, /* Success. */ PS_ERR, /* Generic error. */ PS_BADPID, /* Bad process handle. */ PS_BADLID, /* Bad LWP id. */ PS_BADADDR, /* Bad address. */ PS_NOSYM, /* Symbol not found. */ PS_NOFREGS /* FPU register set not available. */ } ps_err_e; for "err", libthread-db will return "Generic error." However, which ever. Andrew > E01 > The stub-side thread library does not have the required thread local > storage support. > E02 > GDB sent a malformed qGetTLSAddr packet to the stub. > > E03 > The stub was unable to find the thread associated with thread-id. > > E04 > The stub-side thread library was unable to find the TLS address > associated with thread-id, offset, and the OS/ABI specific > parameters. > > Enn (where nn are hex digits and not specfied above) > Some other error occurred. > > "" (empty) > An empty reply indicates that qGetTLSAddr is not supported by the stub. >