Re: [libc patch] __tls_get_addr with link_map * instead of modid

["Carlos O'Donell" <carlos@redhat.com>]

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.