Re: [RFC] Generic support for qGetTLSAddr packet

[Kevin Buettner <kevinb@redhat.com>]

On Mon, 6 Dec 2004 23:37:18 +0100 (CET)
Mark Kettenis <kettenis@gnu.org> wrote:

> Yikes!  That qGetTLSAddr in the function name is really ugly.

Yeah, it is.

Okay, how about something like

    get_remote_TLS_load_module_params

?

> That said, I don't understand why there's any need for the remote code
> to get so deep into the core GDB code.  I don't see the big picture
> yet, but my initial reaction is that this must be wrong.  Why does the
> remote protocol need to know more than a native GDB?

A thread local address is requested via to_get_thread_local_address().
Here's the comment / declaration from target.h:

    /* 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);

Abstracting this only a little bit, the following pieces of information
are needed:

    1) The thread id associated with the thread local storage.  Native
       GDB gets this from ``ptid''.
    2) The load module containing the thread local storage.  Native GDB
       gets this by examining ``objfile''.
    3) The offset provided by the debug information.  (Provided by
       ``offset''.)

(1) and (3) are provided to the stub in an unsurprising fashion.

(2), the load module, is represented by an objfile which is a struct
(pointer) The gdbarch method (whose name you object to) provides a
mechanism by which suitable portions of the objfile struct may be
extracted / translated for benefit of the stub.  As Daniel indicates,
for GNU/Linux, the crucial bit of translation needed by the stub is
the mapping from objfile to a linkmap address.  (This is something that
it would be difficult for the stub to do on its own.) However, this
link map address is simply another representation of the load module,
albeit in a form that's readily usable by the stub.

>    The patch below implements support for the qGetTLSAddr packet.  See:
> 
>        http://sources.redhat.com/ml/gdb/2004-11/msg00189.html
> 
>    This patch also adds a new gdbarch method for fetching the OS / ABI
>    specific load module parameters.
> 
> I don't think this should be added to the "glibal" gdbbarch vector.
> Instead, this probably should be architecture-dependent data that's
> only known to the remote protocol module.

Yeah, this could be done.  I'll look to see what the implications are
of doing it this way...

Kevin