This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [libc patch] __tls_get_addr with link_map * instead of modid
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org, gdb-patches at sourceware dot org
- Date: Fri, 24 Oct 2014 16:40:14 +0200
- 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> <544A60A5 dot 4020701 at redhat dot 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