Re: Proposal: qGetTLSAddr remote protocol packet

[Andrew Cagney <cagney@gnu.org>]

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.
>