Building SPARC CPU code for Zero
David Holmes
david.holmes at oracle.com
Wed Aug 30 21:34:25 UTC 2017
Hi Magnus,
On 30/08/2017 11:25 PM, Magnus Ihse Bursie wrote:
> On 2017-08-30 15:22, Magnus Ihse Bursie wrote:
>> On 2017-08-30 14:02, John Paul Adrian Glaubitz wrote:
>>> Hi!
>>>
>>> I am currently working on fixing JDK-8186578:
>>>
>>> Zero fails to build on linux-sparc due to sparc-specific code
>>>
>>> One necessary change to be able to fix this bug is to build the
>>> SPARC-specific source memset_with_concurrent_readers_sparc.cpp on
>>> Zero as well. This is necessary because on SPARC, we have to use
>>> the custom implementation of memset() to be able to have a working
>>> memset_with_concurrent_readers, the glibc version doesn't work in
>>> this case.
>>>
>>> Now, my first suggested way of addressing this problem was to move
>>> memset_with_concurrent_readers_sparc.cpp into the same location
>>> as memset_with_concurrent_readers.hpp and just make the code in
>>> the former compilation unit conditional so it's built on SPARC
>>> only [1].
>>>
>>> Unfortunately, this proposed change was rejected due to the fact
>>> that it moves SPARC code into a generic location. So, I'm now looking
>>> for a way to tell the build system to build memset_with_concurrent_\
>>> readers_sparc.cpp when building Zero if SPARC is defined.
>>>
>>> Can any build wizard shed some light on this and say whether it's
>>> possible to achieve that?
>>
>> I'm sure it's *possible*. I'm also fairly certain it will be messy. :)
>>
>> Unfortunately, the usage of various defines in presence of zero seems
>> not very well defined. That is, should SPARC be defined alongside
>> ZERO, or should it not be defined when ZERO is defined, if building
>> zero on sparc.
>>
>> The current effect, if I remember correctly, is that both ZERO and
>> SPARC are defined if building zero on sparc, but only SPARC if
>> building a "normal" sparc build. There is also a ZERO_LIBARCH, but I
>> fail to understand the purpose of this.
>>
>> But your problem seems to be that the file itself is not included. I'm
>> not sure how the hotspot include logic determines which platform
>> specific files to include. Possibly they have a "and !definied(ZERO)"
>> in the logic.
> Aha, now I see. It's a .cpp file in cpu/sparc. Hm.
>
> Would it be painful to duplicate the function in cpu/zero? I realize
> this is not elegant, but we don't have a good story for sharing
> platform-specific functionality with zero. :(
Can't we just expand the set of source files to be built when building
Zero for sparc? (Similar to how we reduce the set of source files to
build when building the minimal VM). Sadly I no longer know where such
things are controlled in the build.
Thanks,
David
> /Magnus
>
>
>>
>> /Magnus
>>
>>>
>>> Adrian
>>>
>>>> [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/
>>>
>>
>
More information about the build-dev
mailing list