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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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.


> > 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

For GDB the feedback is usually scarce and skewed to drive design decisions.


> 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.

This decision has been already made by gdb developer Tom Tromey and all the
work (except this TLS issue) has been hopefully already solved now.  I find it
a bit late to throw it all alway and choose a different set of advantages and
disadvantages.


> 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.


Thanks,
Jan