This is the mail archive of the
mailing list for the GCC project.
Re: %fs and %gs segments on x86/x86-64
- From: Armin Rigo <arigo at tunes dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 4 Jul 2015 09:04:15 +0200
- Subject: Re: %fs and %gs segments on x86/x86-64
- Authentication-results: sourceware.org; auth=none
- References: <CAMSv6X19bZpRXf1XexrW0uFONptwHOrcT9T6RegvNDR1_Z5m3A at mail dot gmail dot com> <CAFiYyc2X-bq2YRj5F-=YkR-UfO14cBgYN9qftd3xSt-z+zBUiA at mail dot gmail dot com>
On 3 July 2015 at 10:29, Richard Biener <email@example.com> wrote:
> It's nice to have the ability to test address-space issues on a
> commonly available target at least (not sure if adding runtime
> testcases is easy though).
It should be easy to add testcases that run only on CPUs with the
"fsgsbase" feature, using __builtin_ia32_wrgsbase64(). Either that,
or we have to rely on the Linux-specific system call
arch_prctl(ARCH_SET_GS). Which option is preferred? Of course
we can also try both depending on what is available.
Once %gs can be set, the test case can be as simple as setting it to
the address of some 4096-bytes array and checking that various ways to
access small %gs-based addresses really access the array instead of
>> * One case in which this patched gcc miscompiles code is found in the
>> attached bug1.c/bug1.s.
> Hmm, without being able to dive into it with a debugger it's hard to tell ;)
> You might want to open a bugreport in bugzilla for this at least.
Ok, I will. For reference, I'm not sure why you are not able to dive
into it with a debugger: the gcc patch and the test were included as
>> * The extra byte needed for the "%gs:" prefix is not explicitly
>> accounted for. Is it only by chance that I did not observe gcc
>> underestimating how large the code it writes is, and then e.g. use
>> jump instructions that would be rejected by the assembler?
> Yes, I think you are just lucky here.
Note that I suspect that gcc does overestimates that end up
compensating, otherwise pure luck would likely run out before the end
of the hundreds of MBs of C code. But I agree it is still a bug. I
will look into that more.