RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms

david buck
Hi!

Would you please review this small set of very simple build fixes to hsdis?

bug report: https://bugs.openjdk.java.net/browse/JDK-8185567

proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/

With these changes, hsdis should now correctly build out of the box (no
manual editing of files needed) on Linux with any of the following
return values of "uname -m":

i386
i686
amd64
x86_64
*arm*
aarch64

I made it a point to *not* break anything that previously worked. So,
for example, aarch64 environments will still compile for aarch64 even
when the build target is "all" and not "all64". While forcing it to try
and build a 32-bit binary would be more consistent with what happens
with "make all" on linux-amd64 or solaris-sparcv9, I decided to leave
things as they are in case any aarch64 users depend on the current
behavior. Similarly, an attempt to run "make all" on linux-sparcv9 will
continue to try and build against whatever the return value of "uname
-m" was. Of course running "make all64" now does the right thing and
targets "sparcv9".

Cheers,
-Buck


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms

David Holmes
Hi Buck,

After some extensive offlist discussion the native build support for arm
seems fine, so this is good to go IMHO.

Thanks,
David

On 1/08/2017 10:36 PM, David Holmes wrote:

> Hi Buck,
>
> On 1/08/2017 10:32 PM, David Buck wrote:
>> Hi!
>>
>> It was suggested that I also loop in build-dev to the review of this
>> proposed change.
>
> Thanks for that. As I said in other email the changes seem reasonable,
> but the arm support seems to be for a native arm build whereas we use
> cross-compilation for ARM in the main build. For that matter the arm64
> port also uses cross-compilation.
>
> Cheers,
> David
>
>> Cheers,
>> -Buck
>>
>> On 2017/07/31 22:06, David Buck wrote:
>>> Hi!
>>>
>>> Would you please review this small set of very simple build fixes to
>>> hsdis?
>>>
>>> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567
>>>
>>> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/
>>>
>>> With these changes, hsdis should now correctly build out of the box
>>> (no manual editing of files needed) on Linux with any of the
>>> following return values of "uname -m":
>>>
>>> i386
>>> i686
>>> amd64
>>> x86_64
>>> *arm*
>>> aarch64
>>>
>>> I made it a point to *not* break anything that previously worked. So,
>>> for example, aarch64 environments will still compile for aarch64 even
>>> when the build target is "all" and not "all64". While forcing it to
>>> try and build a 32-bit binary would be more consistent with what
>>> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided
>>> to leave things as they are in case any aarch64 users depend on the
>>> current behavior. Similarly, an attempt to run "make all" on
>>> linux-sparcv9 will continue to try and build against whatever the
>>> return value of "uname -m" was. Of course running "make all64" now
>>> does the right thing and targets "sparcv9".
>>>
>>> Cheers,
>>> -Buck
>>>
>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms

Vladimir Ivanov
In reply to this post by david buck
Looks good!

Best regards,
Vladimir Ivanov

On 8/1/17 5:32 AM, David Buck wrote:

> Hi!
>
> It was suggested that I also loop in build-dev to the review of this
> proposed change.
>
> Cheers,
> -Buck
>
> On 2017/07/31 22:06, David Buck wrote:
>> Hi!
>>
>> Would you please review this small set of very simple build fixes to
>> hsdis?
>>
>> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567
>>
>> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/
>>
>> With these changes, hsdis should now correctly build out of the box
>> (no manual editing of files needed) on Linux with any of the following
>> return values of "uname -m":
>>
>> i386
>> i686
>> amd64
>> x86_64
>> *arm*
>> aarch64
>>
>> I made it a point to *not* break anything that previously worked. So,
>> for example, aarch64 environments will still compile for aarch64 even
>> when the build target is "all" and not "all64". While forcing it to
>> try and build a 32-bit binary would be more consistent with what
>> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided
>> to leave things as they are in case any aarch64 users depend on the
>> current behavior. Similarly, an attempt to run "make all" on
>> linux-sparcv9 will continue to try and build against whatever the
>> return value of "uname -m" was. Of course running "make all64" now
>> does the right thing and targets "sparcv9".
>>
>> Cheers,
>> -Buck
>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(XS): 8185567: fix hsdis cpu to architecture mapping on various Linux platforms

Tim Bell

> On 8/1/17 5:32 AM, David Buck wrote:
>> Hi!
>>
>> It was suggested that I also loop in build-dev to the review of this
>> proposed change.

The build Makefile change looks good.

Tim


On 08/03/17 13:08, Vladimir Ivanov wrote:> Looks good!
 >
 > Best regards,
 > Vladimir Ivanov
 >

>>
>> Cheers,
>> -Buck
>>
>> On 2017/07/31 22:06, David Buck wrote:
>>> Hi!
>>>
>>> Would you please review this small set of very simple build fixes to
>>> hsdis?
>>>
>>> bug report: https://bugs.openjdk.java.net/browse/JDK-8185567
>>>
>>> proposed fix: http://cr.openjdk.java.net/~dbuck/8185567.0/
>>>
>>> With these changes, hsdis should now correctly build out of the box
>>> (no manual editing of files needed) on Linux with any of the
>>> following return values of "uname -m":
>>>
>>> i386
>>> i686
>>> amd64
>>> x86_64
>>> *arm*
>>> aarch64
>>>
>>> I made it a point to *not* break anything that previously worked. So,
>>> for example, aarch64 environments will still compile for aarch64 even
>>> when the build target is "all" and not "all64". While forcing it to
>>> try and build a 32-bit binary would be more consistent with what
>>> happens with "make all" on linux-amd64 or solaris-sparcv9, I decided
>>> to leave things as they are in case any aarch64 users depend on the
>>> current behavior. Similarly, an attempt to run "make all" on
>>> linux-sparcv9 will continue to try and build against whatever the
>>> return value of "uname -m" was. Of course running "make all64" now
>>> does the right thing and targets "sparcv9".
>>>
>>> Cheers,
>>> -Buck
>>>
>>>

Loading...