Building SPARC CPU code for Zero

[Magnus Ihse Bursie]

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. :(

/Magnus


>
> /Magnus
>
>>
>> Adrian
>>
>>> [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.00/
>>
>