This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #17078] ARM: R_ARM_TLS_DESC prelinker support
- From: Rich Felker <dalias at libc dot org>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Wed, 2 Jul 2014 10:41:37 -0400
- Subject: Re: [PATCH][BZ #17078] ARM: R_ARM_TLS_DESC prelinker support
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1406230322570 dot 25395 at tp dot orcam dot me dot uk> <20140701161642 dot GM179 at brightrain dot aerifal dot cx> <alpine dot DEB dot 1 dot 10 dot 1407020830150 dot 16254 at tp dot orcam dot me dot uk>
On Wed, Jul 02, 2014 at 09:39:44AM +0100, Maciej W. Rozycki wrote:
> However this change handles what is already there and supported across
> the toolchain and glibc, fixing a legitimate use case that does not work
> although it should.
If prelink is really broken (errors/crashes at runtime, etc.) on ARM
right now because of this issue, then yes, by all means fix it.
> It is also mostly agnostic about dynamic loading
> implementation internals by merely copying data from the DT_TLSDESC_PLT
> dynamic tag to the memory location pointed by the DT_TLSDESC_GOT tag as
> per the TLS descriptor ARM/Linux psABI addendum. Any change to this
> semantics that your suggested improvements may require will be an
> incompatible ABI change and support for preexisting binaries will have to
> be retained anyway.
I don't think there are any ABI incompatibilities; it's all an
internal implementation detail of the dynamic linker. Of course the
changed dynamic linker would always overwrite these prelinked TLSDESC
relocations at startup since they'd all be lazy.
> There is also GOT[1] initialised here as per our
> practice elsewhere, which is our dynamic linker's internal protocol, and
> obviously any incompatible change of yours will have to address the
> different treatment of GOT[1] throughout our code anyway. But at the
> point you'll have redefined or removed DT_TLSDESC_PLT/DT_TLSDESC_GOT this
> is going to be the least of a problem.
These aren't my proposed changes; they're a natural continuation of
the project that was started (and reverted because it wasn't ready) to
make TLS async-signal-safe and eliminate the possibility of error
conditions that applications fundamentally can't handle at runtime.
Rich