This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64: Align the stack in __tls_get_addr [BZ #21609]
On 07/07/2017 01:13 PM, Alexander Monakov wrote:
> On Fri, 7 Jul 2017, Carlos O'Donell wrote:
>> My apologies, when I wrote 'hot path' I was thinking of process startup
>> where the first call to __tls_get_addr (for a given dtv entry) always goes
>> through the slow path.
>>
>> The reason I still want to highlight this is that there is a non-zero
>> cost paid, and it adds up over time with other decisions we make.
>
> In this case you're talking about literally 5 instructions on paths that
> involve syscalls and thousands of other instructions.
>
> Consider whether bloating the dynamic table by 1 entry and causing
> additional work for the dynamic linker (for all programs by the way,
> not only those using __tls_get_addr) outweighs the cost of those 5
> instructions.
The answer is not black and white.
One must pay the slow path cost for every dtv entry that needs
to be initialized, but one only pays the symbol lookup cost once for
the call to ___tls_get_addr.
One always has to lookup a version of __tls_get_addr, so it might or
might not, cost a little more to have an extra symbol (depends on the
symbol order choices made by the static linker).
The extra .dynamic entry for the triple underscore or versioned symbol
is added to a hash bucket for lookup, and so should be as easy to find
as the original symbol if the new version sorts first.
I think the final decision (a), to keep the original symbol and alter
the slow path to realign the stack (as designed by Florian) is a good
solution. It is a better solution than (c) symbol versioning, but only
because it lacks the downside that recompiling bumps you forward to the
new version which breaks. However, I don't throw out HJ's suggestion
for a new API without giving it due consideration, and it has attractive
benefits. Though I don't see the additional symbol in the .dynsym as a
significant "Con" for that solution, but then again I should try to
experiment with some microbenchmarks.
--
Cheers,
Carlos.