This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [libc patch] __tls_get_addr with link_map * instead of modid
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: libc-alpha at sourceware dot org, gdb-patches at sourceware dot org
- Date: Fri, 24 Oct 2014 10:22:29 -0400
- Subject: Re: [libc patch] __tls_get_addr with link_map * instead of modid
- Authentication-results: sourceware.org; auth=none
- References: <20141018201540 dot GA26252 at host2 dot jankratochvil dot net> <5449B78E dot 1060407 at redhat dot com> <20141024093834 dot GA24090 at host2 dot jankratochvil dot net>
On 10/24/2014 05:38 AM, Jan Kratochvil wrote:
> On Fri, 24 Oct 2014 04:21:02 +0200, Carlos O'Donell wrote:
>> On 10/18/2014 04:15 PM, Jan Kratochvil wrote:
>>> Other option suggested by Tom Tromey is implemented by this patch:
>>>
>>> * A new glibc function like __tls_get_addr that takes a link_map address
>>> rather than a module id.
>>
>> I do not think this is a good solution.
>>
>> If you use this function in jit'd code, you've now deviated from what normal
>> TLS-accessing sequences look like.
>
> Normal TLS-accessing sequences depend on R_X86_64_DTPMOD64 which the GDB JIT
> module cannot depend on. Therefore it will be always deviated.
The only purpose of that relocation is to insert the module id once known,
thus gdb has to act like a dynamic loader in this respect. What's wrong with
using libthread_db to get the module ID and then you can call the normal TLS
functions instead of adding to ld's permanent and future ABI and API?
> TBH - a bit OT - the whole GDB JIT functionality has many arch specific issues
> and deviations due to the initial decision not to use dlopen() for the GDB JIT
> module because dlopen() may do some unexpected modifications of the inferior.
> I was proposing to simply use dlopen(), Tom Tromey required the mmap(), custom
> loading, custom relocations etc. With dlopen() TLS would not be any issue.
I don't understand the tradeoffs, but if calling dlopen() in the inferior would
have made life easy, then I would have done that first, regardless of the impact
on the inferior. Only if users complained or found use cases where things broke
would I have fallen back on the "technical purist" solution involving doing
everything yourself. Those are decisions that you, as a gdb developer need to
make, or reevaluate and make different.
What I oppose is the addition to ld's ABI and API something which is not going
to be a permanent solution, and for which we can put a function somewhere
else and get similar results. The ABI and API for ld is forever, and I change
it only with extreme circumspection.
>> I don't like libthread_db either, but it avoids us having to put a stop-gap
>> API in ld. I say stop-gap because the real solution is going to be to use
>> python/DWARF, not any API in ld.
>>
>> I'm in favour of exactly 3 things:
>>
>> * New function in libthread_db.
>>
>> * Heuristics in gdb if libthread_db is not new enough.
>>
>> * A python or DWARF based parser to replace libthread_db.
>
> I do not see how libthread_db or its equivalents could be applicable.
Isn't a solution to use libthread_db to get the module ID from the link_map,
then use that with normal __tls_get_addr instead of adding to ld's API?
Please correct me if I'm wrong.
> I have attached a use case for GDB JIT to make the problem clear.
> Equivalently 'tlsvar' could be placed into a shared library instead of the
> main executable.
OK.
> When the GDB JIT code needs to access 'tlsvar' it already runs independently
> from GDB. And inferior does not (and as directed by Tom Tromey above it
> should not) dlopen() libthread_db on its own.
If gdb knows the link map for tlsvar it can use libthread_db to lookup the
module ID, and then when compiling code to access TLS it can call __tls_get_addr?
Is that not possible because of something in the JIT?
Cheers,
Carlos.