RFR: 8256618: Zero: Linux x86_32 build still fails [v4]

[Thomas Stuefe]

On Mon, 23 Nov 2020 10:43:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> I guess I'm somewhat surprised that Zero doesn't need anything that is in os_linux_x86.cpp when building for x86. It sets a bad precedent to move CPU specific code to shared code just because zero doesn't conform to the expected use of cpu specific code.
>> 
>> The way current sources are structured, Zero is the "cpu" unto itself. See that we have `os_cpu/linux_x86` and `os_cpu/linux_zero`, `os/linux` and `os/zero`, etc. I agree it is awkward and have consequences like this patch; it has even more consequences for error handling that wants to do arch-specific decoding... 
>> 
>> That said, the current patch just moves the IA32 definition to `os_linux.cpp`, where the IA32 use already is, and this IMO makes it a tad more consistent than it was before.
>> 
>>> Does Zero actually need this code, or could we make the call conditional?
>> 
>> I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around.
>
>> 
>> I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around.
> 
> Well, if we assume Zero will never be used on x86, which seems reasonable, then it doesn't matter. But if it will be used, then there is a real problem with the invocation interface.

I don't think Zero x86 is widely built or tested so no-one may have noticed until now.

I prefer this to be fixed too. Why leave this unfixed if we can fix it.

If we do not want code duplication but putting it into os_linux.cpp is an eyesore, I'd suggest to move it into an own implementation file, e.g. "os/linux/x86_exec_shield_workaround.cpp", with a clear comment that this is needed for zero.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1310