[Bug nptl/17381] New: Access TLS address space of inferior's threads from gdb

[Bug nptl/17381] New: Access TLS address space of inferior's threads from gdb

[siddhesh at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17381

            Bug ID: 17381
           Summary: Access TLS address space of inferior's threads from
                    gdb
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: siddhesh at redhat dot com
                CC: drepper.fsp at gmail dot com

Currently there is no standard way to access the TLS area of an arbitrary
thread from within gdb without intimate knowledge about the layout of the TLS
address space or the module id for dynamic tls, both of which could change.  It
would be good to have a standard, supported interface in glibc that allows the
debugger (and any diagnostic tool for that matter, like valgrind, asan, etc.)
to inspect the TLS area for arbitrary threads in the attached process.

For further information, see [1].

[1] https://sourceware.org/glibc/wiki/Tools%20Interface%20NG

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17381] Access TLS address space of inferior's threads from gdb

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17381

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
I've been talking to some gdb folk and I think the best solution is one more
function added to libthread_db. While I don't think libthread_db is a good
solution for cross-debugging and more complex scenarios that we want to support
it *is* a good place to document via APIs all of the niggling things we need to
share between glibc<->gdb. So rather than have gdb hard code knowledge about
glibc, it should go in libthread_db, and eventually into some kind of
python/dwarf magic that is a data descriptivie way to express the same things
the API expresses.

To this end I'm going to add a new libthread_db function to get the module id
out of the link map and that should be enough for gdb to be able to write out
code to access TLS in the inferior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.