This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Proposal: qGetTLSAddr remote protocol packet
- From: Andrew Cagney <cagney at gnu dot org>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 15 Nov 2004 21:06:03 -0500
- Subject: Re: Proposal: qGetTLSAddr remote protocol packet
- References: <20041105154438.7676aa13@saguaro>
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.