This is the mail archive of the
mailing list for the glibc project.
Re: [PR19826] fix non-LE TLS in static programs
On Sep 26, 2016, Andreas Schwab <email@example.com> wrote:
> If you have to modify it anyway, would you mind adding the testcase from
> the bug?
The reason I didn't add the testcase was that I understood it was
redundant with another existing test. Reviewing the earlier report, I
got the idea that the regression introduced by last year's patch had
already been detected by existing tests on the affected platforms, it
just so happened that I missed the report.
Ideally, we'd have a test to detects such a regression on x86_64 too,
but I don't see a way to do that that's not too fragile. Like, we could
introduce a TLS variable in the main program (so that it's hopefully
assigned to the beginning of the TLS block), include the custom
implementation of tls_get_addr in the test, and call it (with module id
1 and offset 0) to ensure it returns the same address that LE computes
for the variable.
There might be issues with different calling conventions for
tls_get_addr, but if we introduced the custom function using a different
name and a standardized calling convention (even if different from the
one used by the TLS implementation), maybe we'd be able to catch such
regressions. But we'd be taking too different a path from the normal
use of __tls_get_addr to make the test reliable, not to mention the
undeserved assumption that, just because a TLS variable is defined in
the first object file to be linked in, its dynamic TLS offset is going
to be zero.
Do you all think it make sense to introduce such a test, in spite of all
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer