This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [BZ #19679] [x86_64] Set DL_RUNIME_UNALIGNED_VEC_SIZE to 8
- From: Florian Weimer <fweimer at redhat dot com>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 20 Feb 2016 13:05:46 +0100
- Subject: Re: [PATCH] [BZ #19679] [x86_64] Set DL_RUNIME_UNALIGNED_VEC_SIZE to 8
- Authentication-results: sourceware.org; auth=none
- References: <20160219220955 dot GA25540 at intel dot com> <56C79D14 dot 1050900 at redhat dot com> <CAMe9rOr9ewbZEj_AY_pLv8GUWju=ZxVNbOgQ1FxO_6Z5vL8EXQ at mail dot gmail dot com> <56C82616 dot 6010506 at redhat dot com> <20160220091617 dot GA302 at x4>
On 02/20/2016 10:16 AM, Markus Trippelsdorf wrote:
> On 2016.02.20 at 09:38 +0100, Florian Weimer wrote:
>> On 02/20/2016 12:49 AM, H.J. Lu wrote:
>>> +#ifndef DL_RUNTIME_UNALIGNED_VEC_SIZE
>>> +/* The maximum size in bytes of unaligned vector load and store in the
>>> + dynamic linker. Since SSE optimized memory/string functions with
>>> + aligned SSE register load and store are used in the dynamic linker,
>>> + we must set this to 8 so that _dl_runtime_resolve_sse will align the
>>> + stack before calling _dl_fixup. */
>>> +# define DL_RUNTIME_UNALIGNED_VEC_SIZE 8
>> The comment doesn't really explain the situation. If all programs
>> actually fallowed the psABI, we wouldn't need this.
>> I think it's easier at this point to change the psABI to say that
>> __tls_getaddr can be called with an 8-byte-aligned stack.
> I think this would be an overreaction.
I don't know. If glibc will keep this compatibility code indefinitely,
it's easy for other toolchains to make the same mistake.
> It is actually quite hard to hit the issue in practice. You would have
> to build glibc with gcc-6 and -O3, to get the SSE instructions that
> require proper alignment in the dynamic linker.
We will gradually get more SSE instructions in glibc, including the
> And then you have to use it with an old and buggy libstc++ from
I assume that could happen with TLS support in binaries from older
> One could argue that it isn't really the job of the dynamic linker to
> fix unaligned stacks.
Correct, so why are we doing it? It would be pretty drastic to tell
users to throw away their old binaries because they were built with a