[8u] RFR: JDK-8164041: support old pre-c++11 toolchains and ucLibc

[Andrey Petushkov]

Hi Ed,

The reason of the build failure is that it’s apparently tries to build for ARMv6 or earlier target. So in order to fix it you got to provide something like march=armv7-a or respective mcpu. However this makes me think I’ve gone a wrong way a bit. The problem is that the C1 (we’ve almost finished) is only implemented for the targets starting from ARMv6K which do have ldrexd/strexd instructions and hence it’s perfectly legal for us to statically build for these targets. However the interpreter is good to work on pure v6 (but only on single-core device) so it’s wrong to require ARMv6K dependency at build time…
So then it looks like I should return back the builtins. At the same following exactly the reasoning you have provided I’d prefer to use assembly first, and only go with builtins if the assembly version is not suitable.

Thank you,
Andrey

> On 17 Aug 2016, at 13:10, Edward Nevill <edward.nevill at gmail.com> wrote:
> 
> Hi Andrey,
> 
> I tried applying your patch and got the following errors
> 
> Compiling
> /work/ed/aarch32/jdk8u/hotspot/src/share/vm/runtime/atomic.cpp
> {standard input}: Assembler messages:
> {standard input}:254: Error: selected processor does not support ARM
> mode `ldrexd r4,r5,[r2]'
> {standard input}:269: Error: selected processor does not support ARM
> mode `ldrexd r4,r5,[r2]'
> {standard input}:288: Error: selected processor does not support ARM
> mode `ldrexd r8,r9,[r2]'
> {standard input}:291: Error: selected processor does not support ARM
> mode `strexdeq r3,r6,r7,[r2]'
> 
> This was running on a trusty chroot using gcc 4.9.1 on a Samsung
> Chromebook (ARM v7).
> 
> In general I would prefer to use the builtin atomics where possible.
> 
> However I do have some sympathy with the logic that says lets just do
> it in assembler because we know it is right then and we can't trust
> gcc.
> 
> This comes from debugging the atomic primitives on aarch64 and
> discovering they were broken in certain versions of gcc. And the
> problem is, if they are broken on one version of gcc they might as well
> be broken in all versions because, for sure, someone, someday, will use
> the broken version and we will end up debugging it.
> 
> So I am not religious about using builtins or not. Other people on the
> list may have stronger opinions.
> 
> However, it must build on my system. I will continue looking at why it
> isn't building.
> 
> All the best,
> Ed.
> 
> 
> 
> On Mon, 2016-08-15 at 19:06 +0300, Andrey Petushkov wrote:
>> Hi All,
>> 
>> We met a necessity to support an older kind of gcc toolchain which
>> does not fully conform to c++ 11 and in particular do not have
>> __atomic API as well as have some other peculiarities. In addition
>> the support of ucLibc was desired.
>> 
>> The resulting changes are here: http://cr.openjdk.java.net/~apetushko
>> v/8164041/webrev/
>> <http://cr.openjdk.java.net/~apetushkov/8164041/webrev/>
>> Checked with running on OpenWRT-based distribution
>> 
>> When implementing the replacement code we also chosen to always use
>> the assembly implementation and not builtins because:
>> - there is no harm, the assembly is no worse than that gcc can
>> generate
>> - the code is more clear
>> - there is no reliable way to determine if gcc has flaws or not, so
>> the detection directives look really ugly
>> 
>> Thanks,
>> Andrey
>