Hi Richard, On 3 July 2015 at 10:29, Richard Biener <richard.guent...@gmail.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 segfaulting. >> * 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 attachements... >> * 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. A bientôt, Armin.
