Re: tls, valgrind gdbserver and qGetTLSAddr

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

On Wed, 2014-08-13 at 16:10 +0530, Siddhesh Poyarekar wrote:
> On Thu, Aug 07, 2014 at 12:07:13AM +0200, Philippe Waroquiers wrote:
> > On Wed, 2014-08-06 at 17:17 +0400, Konstantin Serebryany wrote:
> > > This question rings the bell...
> > > https://sourceware.org/ml/libc-alpha/2014-04/msg00313.html
> > > https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
> > 
> > Yes, there are similarities in some of the needs.
> > There are also some differences, e.g. Valgrind observes
> > most of what happens by intercepting or wrapping syscalls
> > or glibc calls (eg pthread creation or dead) and
> > Valgrind (at least currently) is also not supposed to call any
> > library to do its work (this is why valgrind cannot use
> > libthread_db).
> 
> But then isn't calling into glibc to get the offset better than having
> to hardcode it?
Currently, no way to have Valgrind calling glibc (or any other lib).
Supporting such calls was quickly discussed on #valgrind-dev, and
was summarised as: 'this is unknown territory, full of lions, snakes and
other dangerous beasts'.

Getting offset(s) can however be done by Valgrind, by launching
an external program. This is in fact what I am currently doing
to get the offset of the module id field in the struct link_map,
but using a kludge to get the offset.
(see patch in https://bugs.kde.org/show_bug.cgi?id=338160 ).
An API to get such offsets (to be called in an external program)
would avoid the kludge in this external program.

> 
> Of course, the ThreadPropertiesAPI is still evolving as an idea and it
> would be awesome to have all diagnostic tools that need it (gdb,
> valgrind, *san), give feedback to the design.  Oh yeah, and if someone
> volunteers to hack it up, that would be even better :)
If you want to validate a proposal, for sure, you are welcome to hack
on Valgrind to test with a real life case :)

Philippe