RFR (T) 8248271: linux-x86-zero build failure

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Thu Jun 25 16:41:05 UTC 2020



On 6/25/20 11:58 AM, Andrew Hughes wrote:
> On 25/06/2020 00:14, coleen.phillimore at oracle.com wrote:
>> See bug for description.  A declaration was missing in os_linux_zero.hpp
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/2020/8248271.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8248271
>>
>> mach5 remote-build -b
>> linux-x64-zero,linux-x64-zero-debug,linux-x86-zero,linux-x86-zero-debug
>>
>> Thanks,
>> Coleen
>>
>> ps. I didn't break this!
>>
> This is a long-standing issue:
>
> https://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-July/028503.html
>
> but clearly tested by so few that no-one has ever been motivated to make
> this change upstream! We've carried it downstream in IcedTea for over
> half a decade, but I've never really run into it myself, as it's rare
> that I'd build for x86-32, never mind x86-32+Zero.
>
> I would suggest going the !defined(ZERO) code rather than building the
> JDK-8023956 hack on Zero x86. I'm not sure how much sense it even makes
> to have that code when there is no JIT.

Sorry, I wasn't expecting more feedback so I checked it in. Thank you 
for your comments though.

Unfortunately now in os_linux.cpp, this code now has an 'else' clause, 
so it's not as nice to add !defined(ZERO.

I can only build linux_x86_zero, but I cannot test it.  Does calling 
workaround_expand_exec_shield_cs_limit cause a problem, even if not 
necessary?

If so, we should #ifndef ZERO in the body of 
workaround_expand_exec_shield_cs_limit if we fix this further.  Let me 
know if you can test this, and I'll make that change if needed.

thanks,
Coleen
>
> Thanks,



More information about the hotspot-runtime-dev mailing list