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

["Carlos O'Donell" <carlos at redhat dot com>]

On 10/24/2014 10:40 AM, Jan Kratochvil wrote:
> On Fri, 24 Oct 2014 16:22:29 +0200, Carlos O'Donell wrote:
>> What's wrong with using libthread_db to get the module ID and then you can
>> call the normal TLS functions
> +
>> 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?
> 
> I forgot about this possibility - that libthread_db would provide just the
> module ID (and not some per-thread address).
> 
> Therefore going to post a libthread_db patch later, instead of using
> _dl_tls_get_addr_soft() which would have one disadvantage I described before
> to Alex.
 
That sounds good to me. If you remember I promised you that I'd implement this,
but I haven't gotten to it yet. If you want to implement it, please go ahead,
otherwise I'll get to adding the function to libthread_db and testing. Right
now though I'm handling other deeper issues (dlopen recursion). So any help
you're willing to give is appreciated. I'm happy to review patches.
 
>> 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.
> 
> IMO the dlopen() way could be the first simple solution, extending it
> optionally only upon demand later.  Going now back to dlopen() seems a bit
> backwards to me.

I don't judge you. That is a decision the gdb community has to make. It sounds
like you've made it. I'm here to help :-)

Cheers,
Carlos.