[aarch64-port-dev ] [aarch32-8u] RFR: 8178318: SUN_ARCH_ABI property not set or in release file for aarch32 builds

Fri Apr 7 13:25:25 UTC 2017

Andrey,

I haven’t looked at any of your other files related to compiler flags for ARM but I don’t
think you should add a new configure option when one already exists in JDK 9.

The ABI name is very much dependent on the compiler flags used to build the native binaries.
Simply specifying the abi name can cause incorrect builds to be produced.

I suggest that you use —with-abi-profile so that when you transition to JDK9, you won’t have
to revisit this issue.

Bob.

> On Apr 7, 2017, at 8:54 AM, Andrey Petushkov <andrey.petushkov at gmail.com> wrote:
> 
> Dear All,
> 
> I’ve made relevant changes into our internal repos to account for this property. If you’d like I’ve prepared a webrev for integration of those into aarch32-8u repos.
> the root of the forest http://cr.openjdk.java.net/~apetushkov/8178318/webrev/ <http://cr.openjdk.java.net/~apetushkov/8178318/webrev/>
> the jdk repo http://cr.openjdk.java.net/~apetushkov/8178318/jdk/webrev/ <http://cr.openjdk.java.net/~apetushkov/8178318/jdk/webrev/>
> 
> I see no point in integration the whole Oracle’s files.m4 machinery. At the same time requirement to pass the value with —with-extra-flags seem to be too loose to ensure the mechanism continues to function in time. So I’ve created a (mandatory) —with-abi-name parameter to configure script
> 
> Regards,
> Andrey
> 
>> On 06 Apr 2017, at 19:03, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com>> wrote:
>> 
>> On 06/04/2017 13:25, Andrey Petushkov wrote:
>>>> On 05 Apr 2017, at 21:39, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>>> wrote:
>>>> 
>>>> On 05/04/2017 15:50, Andrey Petushkov wrote:
>>>>>> On 05 Apr 2017, at 17:31, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>>> wrote:
>>>>>> 
>>>>>> On 05/04/2017 14:43, Andrey Petushkov wrote:
>>>>>>> Dear Simon,
>>>>>>> Sorry for the delay. I was trying to build the code so that it has the property, but apparently the necessary piece of magic is missing. The location for that piece is only present in the Oracle’s arm port repos, not anywhere else, including stock OpenJDK 8u and 9. I doubt we want to integrate it just because of this property. So we will think how to play around it..
>>>>>> Thanks for this information.  This is turning out to be more difficult
>>>>>> than I expected.
>>>>> The instructions from Bob should not be hard to follow. Although I’m not quite sure the —with-extra-cflags is the best implementation it should be good for you
>>>> 
>>>> Are you suggesting that I should create and test a patch for 8u based on
>>>> Bob's instructions and submit it for merging into the 8u codebase?
>>> No, not in any way. And indeed, Bob’s instructions for 8u cannot make any patch since they are for the entity which runs configure script. Which is user. Which is not a part of the repos :)
>> 
>> Thanks, I see now that the #ifdefs that Bob mentioned are present in the
>> jdk8u sources but in different files.  I will give this a try.
>> 
>>>> 
>>>>>>>> 03 Apr 2017, at 23:57, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>>> wrote:
>>>>>>>> 
>>>>>>>> Hi Andrey,
>>>>>>>> I am using the OpenJDK sources in the aarch32-port repository to build
>>>>>>>> a JRE for my application, so it will help to have this property set by
>>>>>>>> this JRE.  I will try my current binary to see whether this property
>>>>>>>> is already available.
>>>>>>> If you’re building from Oracle’s port I believe Bob should be able to tell how to bring the magic over. Otherwise please stay tuned, we’ll work on bringing it into the rest of aarch32 repos
>>>>>> For JDK 8, I am building aarch32-port/jdk8u.  For JDK 9, I was building
>>>>>> aarch32-port/arm-3264.  Since this has been merged into jdk9/jdk9 I am
>>>>>> now building jdk9/jdk9 instead.
>>>>>> 
>>>>>>>> I have sucessfully built the aarch32-port sources for gnueabihf but I
>>>>>>>> could not build them for gnueabi becaise there appear to be some missing
>>>>>>>> files in the aarch32-port sources that are neeeded for softfp support.
>>>>>>>> Is this correct?  If so, are there any plans to support a softfp version?
>>>>>>> Could you please indicate what repos are you building from: 8u, 9 or 9-arm3264 (aka Oracle)
>>>>>> See above.  I have got softfp working with 9-arm3264 but I wasn't able
>>>>>> to build 8u with softfp because of missing files.
>>>>> What files are you missing? Could you please elaborate a bit?
>>>> 
>>>> I will go back and recheck on the details and post here when I have them.
>>>> 
>>>>> One more question, is softfp is mandatory for you? The reason why I’m asking is that we’re regularly building 8u in soft-float configuration with VFP support in hotspot compiler. It should give almost the same performance as softfp. As what to softfp itself it might be broken, we’re not testing it
>>>> 
>>>> I would like to run 8u on ARMv5 machines that only support gnueabi and
>>>> don't have hardware floating-point support.  I have built a JDK9 runtime
>>>> for this from the 9-arm3264 sources and I have verified that it works.
>>> A-ha, then the problem should be not in VP but rather in ARMv5. Sorry to say but aarch32-8u codebase does not support any ARM core lower than v6k. (Although it should be pretty easy to make interpreter work on v5 and even below)
>> 
>> Thanks for the clarification.
>> 
>> Simon
>> 
>>> Andrey
>>>> 
>>>> Simon
>>>> 
>>>>> Thanks,
>>>>> Andrey
>>>>>> Simon
>>>>>> 
>>>>>>> Thanks,
>>>>>>> Andrey
>>>>>>>> Best regards,
>>>>>>>> Simon
>>>>>>>> 
>>>>>>>> On 03/04/2017 21:45, Andrey Petushkov wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>> from the first glance it's set with the command line when the binary is built.  so there is no code change is required but rather build system setup.  we can ensure Azul is building with it so it will propagate into any downstream distribution taking our binaries. yet it might help you or might not depending on what you call the "openjdk build"
>>>>>>>>> Regards,
>>>>>>>>> Andrey
>>>>>>>>> On Mon, Apr 3, 2017, 23:18 Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>>> wrote:
>>>>>>>>> On 03/04/2017 17:58, Bob Vandette wrote:
>>>>>>>>>  > The Oracle binaries for JDK 8 and JDK 9 Linux arm already include
>>>>>>>>> this property for the
>>>>>>>>>  > 32-bit ARM binaries.
>>>>>>>>>  >
>>>>>>>>>  > The only release that in question is the 64-bit aarch64 Linux
>>>>>>>>> distribution.  There’s really
>>>>>>>>>  > no need for this property since there’s only 1 ABI that’s widely
>>>>>>>>> used today on that
>>>>>>>>>  > architecture.
>>>>>>>>>  >
>>>>>>>>>  > Bob.
>>>>>>>>>  >
>>>>>>>>> My comment was about the OpenJDK aarch32 builds.  From your original
>>>>>>>>> post,
>>>>>>>>> I have the impression that the OpenJDK aarch32 builds don't set this
>>>>>>>>> property.
>>>>>>>>> If it could be added for the OpenJDK aarch32 builds, this would be
>>>>>>>>> very useful
>>>>>>>>> for my application.
>>>>>>>>> I understand that this is not needed for aarch64 builds.
>>>>>>>>> Simon
>>>>>>>>>  >> On Apr 3, 2017, at 12:53 PM, Simon Nash <simon at cjnash.com <mailto:simon at cjnash.com> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>>
>>>>>>>>> <mailto:simon at cjnash.com <mailto:simon at cjnash.com>>> wrote:
>>>>>>>>>  >>
>>>>>>>>>  >> Hi Bob,
>>>>>>>>>  >> I would find such a property very useful.
>>>>>>>>>  >>
>>>>>>>>>  >> My application is mostly written in Java but also uses a native
>>>>>>>>> library
>>>>>>>>>  >> that is loaded dynamically by the Java code.  In order to distribute
>>>>>>>>>  >> fewer versions of the application and make things simpler for users,
>>>>>>>>>  >> I have recently started packaging multiple versions of the
>>>>>>>>> native library
>>>>>>>>>  >> (for example, Intel x86 and Intel x64) in a single version of the
>>>>>>>>>  >> application and using Java runtime properties to determine which of
>>>>>>>>>  >> these native libraries to load.
>>>>>>>>>  >>
>>>>>>>>>  >> I would like to do this for gnueabi and gnueabihf if I could find a
>>>>>>>>>  >> reliable way to determine at runtime which of these native libraries
>>>>>>>>>  >> is needed.  It sounds like this property would be an ideal solution.
>>>>>>>>>  >>
>>>>>>>>>  >> Best regards,
>>>>>>>>>  >> Simon
>>>>>>>>>  >>
>>>>>>>>>  >> On 03/04/2017 16:57, Bob Vandette wrote:
>>>>>>>>>  >>> I’m inclined to not fix this bug but thought I’d bring it to
>>>>>>>>> your attention just in case.
>>>>>>>>>  >>> I assume that OpenJDK ARM builds never set this property
>>>>>>>>> anyway, right?
>>>>>>>>>  >>> https://bugs.openjdk.java.net/browse/JDK-8177976 <https://bugs.openjdk.java.net/browse/JDK-8177976>
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8177976 <https://bugs.openjdk.java.net/browse/JDK-8177976>>
>>>>>>>>>  >>> Bob.
>>>>>>>>>  >
>>>>>>>>>  >
>> 
> 