date:20180905

It might be UBSan false positive :) What about ASan? 
https://bugs.openjdk.java.net/browse/JDK-8189800



在 2018年09月06日 09:12, Martin Buchholz 写道:
it's difficult to use llvm tools like sanitizers on openjdk sources, 
because of the "cheating" - relying on undefined behavior, and the JIT.


On Wed, Sep 5, 2018 at 6:09 PM, Leslie Zhai > wrote:


Hi Martin,

Thanks for your response!

I haven't tested compiling OpenJDK 12-dev with LLVM toolchain,
perhaps the issue had been fixed already, because clang treat
invalid argument '-std=gnu++98' not allowed with 'C' as error.  It
is better only apply EXTRA_CFLAGS to C without EXTRA_CXXFLAGS.

Furthermore, I just have interest, did you use clang analyzer,
sanitizer and libfuzzer towards hotspot and jdk native library?
Thanks!


在 2018年09月06日 02:10, Martin Buchholz 写道:

We seem to have some confusion about flags for C vs. flags for
C++.  Most flags for most toolchains apply to both C and C++,
so it's understandable that we want to unify them.  But some
flags, notably -std, are language-specific.  We have both
EXTRA_CFLAGS and EXTRA_CXXFLAGS, so we should expect
EXTRA_CFLAGS to only apply to C.


-- 
Regards,

Leslie Zhai





--
Regards,
Leslie Zhai

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

2018-09-05 Thread Martin Buchholz

it's difficult to use llvm tools like sanitizers on openjdk sources,
because of the "cheating" - relying on undefined behavior, and the JIT.

On Wed, Sep 5, 2018 at 6:09 PM, Leslie Zhai  wrote:

> Hi Martin,
>
> Thanks for your response!
>
> I haven't tested compiling OpenJDK 12-dev with LLVM toolchain, perhaps the
> issue had been fixed already,  because clang treat invalid argument
> '-std=gnu++98' not allowed with 'C' as error.  It is better only apply
> EXTRA_CFLAGS to C without EXTRA_CXXFLAGS.
>
> Furthermore, I just have interest, did you use clang analyzer, sanitizer
> and libfuzzer towards hotspot and jdk native library? Thanks!
>
>
> 在 2018年09月06日 02:10, Martin Buchholz 写道:
>
>> We seem to have some confusion about flags for C vs. flags for C++.  Most
>> flags for most toolchains apply to both C and C++, so it's understandable
>> that we want to unify them.  But some flags, notably -std, are
>> language-specific.  We have both EXTRA_CFLAGS and EXTRA_CXXFLAGS, so we
>> should expect EXTRA_CFLAGS to only apply to C.
>>
>
> --
> Regards,
> Leslie Zhai
>
>
>

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option


Hi Martin,

Thanks for your response!

I haven't tested compiling OpenJDK 12-dev with LLVM toolchain, perhaps 
the issue had been fixed already,  because clang treat invalid argument 
'-std=gnu++98' not allowed with 'C' as error.  It is better only apply 
EXTRA_CFLAGS to C without EXTRA_CXXFLAGS.


Furthermore, I just have interest, did you use clang analyzer, sanitizer 
and libfuzzer towards hotspot and jdk native library? Thanks!


在 2018年09月06日 02:10, Martin Buchholz 写道:
We seem to have some confusion about flags for C vs. flags for C++.  
Most flags for most toolchains apply to both C and C++, so it's 
understandable that we want to unify them.  But some flags, notably 
-std, are language-specific.  We have both EXTRA_CFLAGS and 
EXTRA_CXXFLAGS, so we should expect EXTRA_CFLAGS to only apply to C.


--
Regards,
Leslie Zhai

Re: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig


On 6/09/2018 8:13 AM, Magnus Ihse Bursie wrote:



6 sep. 2018 kl. 00:00 skrev David Holmes :

Hi Magnus,


On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig 
started failing on Solaris, and that part was backed out.
Here's a new, and improved solution to remove the mapfile for libjsig, even on 
Solaris.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01


Why are the forward declarations Solaris-only when the actual function 
definitions add JNIEXPORT unconditionally?


No other toolchain has a problem when the definition of the functions adds 
JNIEXPORT (i.e. adds a visibility attribute) to the initial declaration.

It's certainly possible to do it for the other platforms, but it's not needed 
and I thought it didn't add anything to do it for all platforms. This way it's 
clear that the solstudio compiler is an anomaly.


Okay.



  37  * before including signal.h */
  38 #include "sys/signal.h"

Why do we need to include sys/signal.h rather than just (the existing) signal.h?


Since it includes the definition of the sigaction struct that is needed for the 
sigaction() prototype. (signal.h includes sys/signal.h for type definitions)


Doh! Of course.

Thanks,
David


/Magnus



Thanks,
David


/Magnus

Re: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig

> 6 sep. 2018 kl. 00:00 skrev David Holmes :
> 
> Hi Magnus,
> 
>> On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
>> When I removed (mostly) all mapfiles for the JDK libraries, building of 
>> libjsig started failing on Solaris, and that part was backed out.
>> Here's a new, and improved solution to remove the mapfile for libjsig, even 
>> on Solaris.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01
> 
> Why are the forward declarations Solaris-only when the actual function 
> definitions add JNIEXPORT unconditionally?

No other toolchain has a problem when the definition of the functions adds 
JNIEXPORT (i.e. adds a visibility attribute) to the initial declaration. 

It's certainly possible to do it for the other platforms, but it's not needed 
and I thought it didn't add anything to do it for all platforms. This way it's 
clear that the solstudio compiler is an anomaly. 

> 
>  37  * before including signal.h */
>  38 #include "sys/signal.h"
> 
> Why do we need to include sys/signal.h rather than just (the existing) 
> signal.h?

Since it includes the definition of the sigaction struct that is needed for the 
sigaction() prototype. (signal.h includes sys/signal.h for type definitions)

/Magnus

> 
> Thanks,
> David
> 
>> /Magnus

Re: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig


Hi Magnus,

On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote:
When I removed (mostly) all mapfiles for the JDK libraries, building of 
libjsig started failing on Solaris, and that part was backed out.


Here's a new, and improved solution to remove the mapfile for libjsig, 
even on Solaris.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 


Why are the forward declarations Solaris-only when the actual function 
definitions add JNIEXPORT unconditionally?


  37  * before including signal.h */
  38 #include "sys/signal.h"

Why do we need to include sys/signal.h rather than just (the existing) 
signal.h?


Thanks,
David



/Magnus

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation


Hi Severin,

Might as well raise this here too as it's really a build philosophy 
issue. Shouldn't flags like -ffp-contract=off (and the existing AIX 
-qfloat=nomaf) be toolchain specific rather than platform specific?


Thanks,
David

On 5/09/2018 11:12 PM, Severin Gehwolf wrote:

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch intends to turn it on on all arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
  - Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers for
StrictMath:

Function  | before | after
--
sin   | 0m33.382s  | 0m18.731s
cos   | 0m31.562s  | 0m18.796s
tan   | 0m33.657s  | 0m21.093s
atan  | 0m5.714s   | 0m4.902s
log   | 0m6.212s   | 0m4.439s
log10 | 0m7.946s   | 0m5.543s
sqrt  | 0m0.481s   | 0m0.449s
cbrt  | 0m5.295s   | 0m5.214s
tanh  | 0m1.404s   | 0m1.307s
log1p | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2 | 0m8.037s   | 0m5.668s
hypot | 0m2.171s   | 0m2.147s

Thoughts?

Thanks,
Severin

Re: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization


Hi Severin,

On 6/09/2018 4:36 AM, Severin Gehwolf wrote:

Hi,

On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get
compiled with -O0. It appears to be for the same (historical?) reason
as for fdlibm files in core-libs. JDK-8210416 is an attempt to make
this consistent on all Linux arches (as s390x/ppc64/aarch64 already use
that) for fdlibm. This patch does the same for the hotspot copies.
Compile it with OPT and -ffp-contract=off instead of no optimization at
all. Thoughts?


The code in sharedRuntimeTrig is expected/required to be built the same 
way as the fdlibm library as it contains the same code. So if it is okay 
to change the way fdlibm is built then it follows this is okay too. I 
traced this change to the optimization flags back to 2001 but no details 
on the exact issue seen with fdlibm.


Is -ffp-contract=off a gcc-specific flag? If so this should be a gcc 
conditional not a linux-x86 one.


Thanks,
David


webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/
Bug:https://bugs.openjdk.java.net/browse/JDK-8210425

Testing: - make run-test-tier1 (no new failures).
  - Currently running through submit.
  - Verified objects get compiled with -O3 -ffp-contract=off in
build logs.

Thanks,
Severin

Re: RFR: JDK-8056217 Remove awt_makecube.cpp

2018-09-05 Thread Sergey Bylokhov


looks fine.

On 05/09/2018 05:19, Magnus Ihse Bursie wrote:
As per the discussion in JDK-8056217, the file awt_makecube.cpp (which 
is not compiler nor used) should be removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8056217

Change:
$ hg status
R src/java.desktop/windows/native/common/awt_makecube.cpp

/Magnus




--
Best regards, Sergey.

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-05 Thread Gustavo Romero


Hello,

On 09/05/2018 04:15 PM, joe darcy wrote:

Hello,


On 9/5/2018 6:12 AM, Severin Gehwolf wrote:

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch intends to turn it on on all arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8210416
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
  - Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers for
StrictMath:

Function  | before | after
--
sin   | 0m33.382s  | 0m18.731s
cos   | 0m31.562s  | 0m18.796s
tan   | 0m33.657s  | 0m21.093s
atan  | 0m5.714s   | 0m4.902s
log   | 0m6.212s   | 0m4.439s
log10 | 0m7.946s   | 0m5.543s
sqrt  | 0m0.481s   | 0m0.449s
cbrt  | 0m5.295s   | 0m5.214s
tanh  | 0m1.404s   | 0m1.307s
log1p | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2 | 0m8.037s   | 0m5.668s
hypot | 0m2.171s   | 0m2.147s




Note that pow (JDK-8134795), hypot (JDK-7130085), cbrt (JDK-8136799), and exp 
(JDK-8139688), have been ported to Java as of JDK 9. The sqrt method is 
commonly handled as an intrinsic.

Testing that was not geared toward finding precision/rounding issues would be 
unlikely to find them.

I don't see the sources of the microbenchmark in JDK-8170153.


The microbench can be found on the first email I sent discussing that issue on 
Power.
Check it at the end, but there is nothing special in there:

http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-November/002738.html

There is also some discussing on the formal RFR:

http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-November/002751.html

Severin, the precision issues were quite conspicuous on Power when -O3 was 
turned on.
There are some discussions about it in the threads above IIRC. SAP helped to 
test the
change against additional tests, like TCK.

HTH.


Best regards,
Gustavo
 

Cheers,

-Joe

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-05 Thread joe darcy


Hello,


On 9/5/2018 6:12 AM, Severin Gehwolf wrote:

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch intends to turn it on on all arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
  - Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers for
StrictMath:

Function  | before | after
--
sin   | 0m33.382s  | 0m18.731s
cos   | 0m31.562s  | 0m18.796s
tan   | 0m33.657s  | 0m21.093s
atan  | 0m5.714s   | 0m4.902s
log   | 0m6.212s   | 0m4.439s
log10 | 0m7.946s   | 0m5.543s
sqrt  | 0m0.481s   | 0m0.449s
cbrt  | 0m5.295s   | 0m5.214s
tanh  | 0m1.404s   | 0m1.307s
log1p | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2 | 0m8.037s   | 0m5.668s
hypot | 0m2.171s   | 0m2.147s




Note that pow (JDK-8134795), hypot (JDK-7130085), cbrt (JDK-8136799), 
and exp (JDK-8139688), have been ported to Java as of JDK 9. The sqrt 
method is commonly handled as an intrinsic.


Testing that was not geared toward finding precision/rounding issues 
would be unlikely to find them.


I don't see the sources of the microbenchmark in JDK-8170153.

Cheers,

-Joe

Re: Linux + Clang + execstack

2018-09-05 Thread Martin Buchholz

So ... Magnus, are you happy with the current state of the proposed patch?

On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
> For the gcc toolchain this can not be the case:
> # Minimum supported linker versions, empty means unspecified
> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
>
> We make sure we have an ld that supports the basic flags we assume.
>

feature tests are better than version tests.  Because there are various
linkers in play (old GNU ld, gold, lld, macosx ld, BSD ld) and we'd like
our compilers to work the same way on various platforms, I'm vaguely
unhappy with TOOLCHAIN_MINIMUM_LD_VERSION_gcc.  It looks
like TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate
toolchains and operating systems.

> We can add a similar check for the clang toolchain, if you want.
>
> Mixing and matching compilers and linkers willy-nilly is not a supported
> build option
>

As always, I am for portability and for toolchain competition.  I'd like to
be able to build with Intel's icc toolchain.

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

2018-09-05 Thread Erik Helin


On 09/05/2018 06:51 PM, Erik Joelsson wrote:
It was pointed out offline that I had missed some "Mercurial" in log 
messages. This webrev also reintroduces the .gitignore file that was 
mistakenly omitted in the last webrev.


http://cr.openjdk.java.net/~erikj/8210283/webrev.03/


Hi Erik,

thanks for fixing this. Looks good, Reviewed.

Thanks,
Erik


/Erik


On 2018-09-04 16:27, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.02/

Fixed the comment in SourceRevision.gmk.

Added an SCM identifier in the string so a typical .src-rev file now 
looks like this:


.:hg:3f189f451ff1+

or like this:

.:git:2e1f2c6d44e5+

/Erik


On 2018-09-04 15:00, Erik Joelsson wrote:
There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project 
Skara aims to investigate Git as well. To better support this, the 
build needs to be able to support Git as an alternative to Mercurial 
when creating the identification hash in the release file. It would 
also be convenient with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization

Hi,

On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get
compiled with -O0. It appears to be for the same (historical?) reason
as for fdlibm files in core-libs. JDK-8210416 is an attempt to make
this consistent on all Linux arches (as s390x/ppc64/aarch64 already use
that) for fdlibm. This patch does the same for the hotspot copies.
Compile it with OPT and -ffp-contract=off instead of no optimization at
all. Thoughts?

webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/
Bug:https://bugs.openjdk.java.net/browse/JDK-8210425

Testing: - make run-test-tier1 (no new failures).
 - Currently running through submit.
 - Verified objects get compiled with -O3 -ffp-contract=off in
   build logs.

Thanks,
Severin

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

2018-09-05 Thread Martin Buchholz

We seem to have some confusion about flags for C vs. flags for C++.  Most
flags for most toolchains apply to both C and C++, so it's understandable
that we want to unify them.  But some flags, notably -std, are
language-specific.  We have both EXTRA_CFLAGS and EXTRA_CXXFLAGS, so we
should expect EXTRA_CFLAGS to only apply to C.

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

Looks good to me. 

/Magnus

> 5 sep. 2018 kl. 18:51 skrev Erik Joelsson :
> 
> It was pointed out offline that I had missed some "Mercurial" in log 
> messages. This webrev also reintroduces the .gitignore file that was 
> mistakenly omitted in the last webrev.
> 
> http://cr.openjdk.java.net/~erikj/8210283/webrev.03/
> 
> /Erik
> 
> 
>> On 2018-09-04 16:27, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.02/
>> 
>> Fixed the comment in SourceRevision.gmk.
>> 
>> Added an SCM identifier in the string so a typical .src-rev file now looks 
>> like this:
>> 
>> .:hg:3f189f451ff1+
>> 
>> or like this:
>> 
>> .:git:2e1f2c6d44e5+
>> 
>> /Erik
>> 
>> 
>>> On 2018-09-04 15:00, Erik Joelsson wrote:
>>> There are several instances of OpenJDK source being hosted in Git 
>>> repositories instead of Mercurial. AdoptOpenJDK is one and some engineers 
>>> use local conversions for their day to day work. Project Skara aims to 
>>> investigate Git as well. To better support this, the build needs to be able 
>>> to support Git as an alternative to Mercurial when creating the 
>>> identification hash in the release file. It would also be convenient with a 
>>> .gitignore file mirroring the .hgignore file.
>>> 
>>> This patch adds such support as well as a .gitignore file.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html
>>> 
>>> /Erik
>>> 
>> 
>

Re: 8210423: Backport of 8034788 breaks GCC version detection


Looks good.

/Erik


On 2018-09-05 09:05, Andrew Haley wrote:

The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
consistently, and as a result the version number check for GCC is
broken. As a result of that brokenness, HotSpot built on all GCC
versions >=6 is unstable.

Intriguingly, the comments aroud te affected code are correct, and
refer to CXX_VERSION_NUMBER, but the actual variable name is wrong.

http://cr.openjdk.java.net/~aph/8210423/

OK?

Re: RFR: JDK-8056217 Remove awt_makecube.cpp


Looks good to me.

/Erik


On 2018-09-05 05:19, Magnus Ihse Bursie wrote:
As per the discussion in JDK-8056217, the file awt_makecube.cpp (which 
is not compiler nor used) should be removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8056217

Change:
$ hg status
R src/java.desktop/windows/native/common/awt_makecube.cpp

/Magnus

Re: RFR: JDK-8081858 make dist-clean does not delete all log files


Looks good.

/Erik


On 2018-09-05 05:12, Magnus Ihse Bursie wrote:
"make dist-clean" leaves build.log and configure.log behind, as well 
as the rotated .old files.


Bug: https://bugs.openjdk.java.net/browse/JDK-8081858
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8081858-fix-dist-clean/webrev.01


/Magnus

Re: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig


Hello,

Looks good to me.

/Erik


On 2018-09-05 05:11, Magnus Ihse Bursie wrote:
When I removed (mostly) all mapfiles for the JDK libraries, building 
of libjsig started failing on Solaris, and that part was backed out.


Here's a new, and improved solution to remove the mapfile for libjsig, 
even on Solaris.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01


/Magnus

Re: RFR 8210318: idea.sh script doesn't work on Mac


Looks good, thanks!

/Erik


On 2018-09-05 04:42, Maurizio Cimadamore wrote:
Here's the modified webrev - as suggested, I replaced /tmp/replacement 
with $1.tmp


http://cr.openjdk.java.net/~mcimadamore/8210318_v2/

Thanks
Maurizio


On 04/09/18 18:50, Erik Joelsson wrote:

Hello,

$TARGET was just pseudo code. In your case it's $1.tmp.

/Erik


On 2018-09-04 10:34, Maurizio Cimadamore wrote:

Hi Erik,
would $TARGET be set by make?

Maurizio


On 04/09/18 16:55, Erik Joelsson wrote:

Hello,

When choosing a temp file in the build, we avoid using /tmp 
whenever possible. A common pattern is instead to write to 
$TARGET.tmp and then mv that to $TARGET. Though unlikely to cause 
an issue, /tmp/replacement is a global location which is 
potentially risky (file permissions, concurrent execution etc).


Otherwise looks good.

/Erik

On 2018-09-03 05:39, Maurizio Cimadamore wrote:

Hi,
following the latest updates to the idea.sh script, Mac users 
reported issues - mostly having to do with usage of 'sed' - more 
specifically:


* sed -i option is not portable - it has different formats in Mac 
vs. Linux. This patch does without -i, by moving the replaced file 
onto a temporary file, then moving such file on top of the 
template file in a subsequent step. This should be more robust.


* sed doesn't like newlines in replaced text in Mac. I've thus 
omitted the newline from the SOURCE template - as that was mostly 
cosmetic.


Thanks for Michael McMahon to report (and figure out how to deal 
with) these issues, and to Alan Bateman for testing the patch.


I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location 
in the various run configuration.


Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210318/

Cheers
Maurizio

Re: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning





On 2018-09-05 04:03, Baesken, Matthias wrote:

Hello,  when compilingjdk/jdk   on Windows,  (with VS2017 update level 15.8 
and not disabling warnings as errors )
I came across  this  warning   leading to build error :

C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
error C2220: warning treated as error - no 'object' file generated
C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
warning C4305: 'argument': truncation from 'const intx' to 'double'

Would have been helpful  to have a compiler flag set  that really   ***shows  
the code***  leading to the warning/error  (because it comes from heavy macro 
expansion).


Do you know of such a flag? If so we certain would like to add it.

/Erik

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

It was pointed out offline that I had missed some "Mercurial" in log 
messages. This webrev also reintroduces the .gitignore file that was 
mistakenly omitted in the last webrev.


http://cr.openjdk.java.net/~erikj/8210283/webrev.03/

/Erik


On 2018-09-04 16:27, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.02/

Fixed the comment in SourceRevision.gmk.

Added an SCM identifier in the string so a typical .src-rev file now 
looks like this:


.:hg:3f189f451ff1+

or like this:

.:git:2e1f2c6d44e5+

/Erik


On 2018-09-04 15:00, Erik Joelsson wrote:
There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project 
Skara aims to investigate Git as well. To better support this, the 
build needs to be able to support Git as an alternative to Mercurial 
when creating the identification hash in the release file. It would 
also be convenient with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

Re: 8210423: Backport of 8034788 breaks GCC version detection

On Wed, 2018-09-05 at 17:05 +0100, Andrew Haley wrote:
> The JDK8u backport of 8034788 changed the variable name CXX_VERSION
> (in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
> consistently, and as a result the version number check for GCC is
> broken. As a result of that brokenness, HotSpot built on all GCC
> versions >=6 is unstable.
> 
> Intriguingly, the comments aroud te affected code are correct, and
> refer to CXX_VERSION_NUMBER, but the actual variable name is wrong.
> 
> http://cr.openjdk.java.net/~aph/8210423/
> 
> OK?

This fixes the issue I was seeing on jdk8u-dev head on F28 with GCC
8.1.1. java -version crashed on release build. That's a +1 from me (not
a Reviewer).

Thanks,
Severin

Re: 8210423: Backport of 8034788 breaks GCC version detection

2018-09-05 Thread Kevin Walls


Hi Andrew,

I think I did that, so must have gone macro-blind by that point. Yes, 
looks good to me.


Thanks
Kevin


On 05/09/2018 17:05, Andrew Haley wrote:

The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
consistently, and as a result the version number check for GCC is
broken. As a result of that brokenness, HotSpot built on all GCC
versions >=6 is unstable.

Intriguingly, the comments aroud te affected code are correct, and
refer to CXX_VERSION_NUMBER, but the actual variable name is wrong.

http://cr.openjdk.java.net/~aph/8210423/

OK?

8210423: Backport of 8034788 breaks GCC version detection

2018-09-05 Thread Andrew Haley

The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
consistently, and as a result the version number check for GCC is
broken. As a result of that brokenness, HotSpot built on all GCC
versions >=6 is unstable.

Intriguingly, the comments aroud te affected code are correct, and
refer to CXX_VERSION_NUMBER, but the actual variable name is wrong.

http://cr.openjdk.java.net/~aph/8210423/

OK?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Can not build jdk10 under Solaris 11

2018-09-05 Thread Gary Adams


With jdk10 repos you should be using solstudio 12.4.
The changes were added to jdk11 repos to begin support
for solstudio 12.6, but there are some additional patches
needed in solstudio 12.6 to be able to build openjdk.
Hopefully those issues will be resolved for the next jdk release.

On 9/5/18, 11:26 AM, Andrew Watkins wrote:

Hello,

I am sure I am doing something wrong, but having build problems with 
OpenJDK under Solaris.


Error:
# gmake
Building target 'default (exploded-image)' in configuration 
'solaris-x86_64-normal-server-release'

Creating support/modules_libs/java.base/libjsig.so from 1 file(s)
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 60: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 67: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 97: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.

3 Error(s) detected.
gmake[3]: *** 
[/var/tmp/jdk10/build/solaris-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/arena.o] 
Error 2

gmake[3]: *** Waiting for unfinished jobs




I can see that there is a bug 8199782 with fixes 
http://hg.openjdk.java.net/jdk/jdk/rev/fa26e7c6efb7, but these fixes 
are not in my version? Am I missing a step to get the right jdk10 
software?


I tried manually altering the code and got further but no point 
discussing that until I know I am pulling the right code down from 
openjdk.


Full steps:

# export 
PATH=/opt/developerstudio/bin:/usr/bin:/usr/sbin:/usr/gnu/bin:/usr/sfw/bin

# hg clone http://hg.openjdk.java.net/jdk10/jdk10
# cd jdk10
# bash get_source.sh
# Repositories:  corba jaxp jaxws langtools jdk hotspot nashorn
 jaxp:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jaxp jaxp
corba:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/corba corba

 jaxp:   requesting all changes
corba:   requesting all changes
corba:   adding changesets
 jaxp:   adding changesets
corba:   adding manifests
 jaxp:   adding manifests
corba:   adding file changes
corba:   added 925 changesets with 5504 changes to 
2597 files

corba:   updating to branch default
corba:   1201 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
jaxws:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jaxws jaxws

jaxws:   requesting all changes
jaxws:   adding changesets
jaxws:   adding manifests
 jaxp:   adding file changes
 jaxp:   added 1217 changesets with 15333 changes to 
8488 files

 jaxp:   updating to branch default
 jaxp:   3343 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
langtools:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/langtools langtools

langtools:   requesting all changes
langtools:   adding changesets
jaxws:   adding file changes
jaxws:   added 850 changesets with 21898 changes to 
10824 files

jaxws:   updating to branch default
jaxws:   3757 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  jdk:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jdk jdk

  jdk:   requesting all changes
langtools:   adding manifests
  jdk:   adding changesets
   langtools:   adding file changes
langtools:   added 4297 changesets with 38693 changes to 
11923 files

langtools:   updating to branch default
langtools:   8702 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  hotspot:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/hotspot hotspot

  hotspot:   requesting all changes
  hotspot:   adding changesets
  hotspot:   adding manifests
  jdk:   adding manifests
  hotspot:   adding file changes
  hotspot:   added 13550 changesets with 85505 changes to 
16280 files

  hotspot:   updating to branch default
  hotspot:   9230 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  nashorn:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/nashorn nashorn

  nashorn:   requesting all changes
  nashorn:   adding changesets
  nashorn:   adding manifests
  nashorn:   adding file

Can not build jdk10 under Solaris 11

2018-09-05 Thread Andrew Watkins


Hello,

I am sure I am doing something wrong, but having build problems with 
OpenJDK under Solaris.


Error:
# gmake
Building target 'default (exploded-image)' in configuration 
'solaris-x86_64-normal-server-release'

Creating support/modules_libs/java.base/libjsig.so from 1 file(s)
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 60: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 67: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 97: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.

3 Error(s) detected.
gmake[3]: *** 
[/var/tmp/jdk10/build/solaris-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/arena.o] 
Error 2

gmake[3]: *** Waiting for unfinished jobs




I can see that there is a bug 8199782 with fixes 
http://hg.openjdk.java.net/jdk/jdk/rev/fa26e7c6efb7, but these fixes are 
not in my version? Am I missing a step to get the right jdk10 software?


I tried manually altering the code and got further but no point 
discussing that until I know I am pulling the right code down from openjdk.


Full steps:

# export 
PATH=/opt/developerstudio/bin:/usr/bin:/usr/sbin:/usr/gnu/bin:/usr/sfw/bin

# hg clone http://hg.openjdk.java.net/jdk10/jdk10
# cd jdk10
# bash get_source.sh
# Repositories:  corba jaxp jaxws langtools jdk hotspot nashorn
 jaxp:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jaxp jaxp
    corba:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/corba corba

 jaxp:   requesting all changes
    corba:   requesting all changes
    corba:   adding changesets
 jaxp:   adding changesets
    corba:   adding manifests
 jaxp:   adding manifests
    corba:   adding file changes
    corba:   added 925 changesets with 5504 changes to 2597 
files

    corba:   updating to branch default
    corba:   1201 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
    jaxws:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jaxws jaxws

    jaxws:   requesting all changes
    jaxws:   adding changesets
    jaxws:   adding manifests
 jaxp:   adding file changes
 jaxp:   added 1217 changesets with 15333 changes to 
8488 files

 jaxp:   updating to branch default
 jaxp:   3343 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
    langtools:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/langtools langtools

    langtools:   requesting all changes
    langtools:   adding changesets
    jaxws:   adding file changes
    jaxws:   added 850 changesets with 21898 changes to 
10824 files

    jaxws:   updating to branch default
    jaxws:   3757 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  jdk:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jdk jdk

  jdk:   requesting all changes
    langtools:   adding manifests
  jdk:   adding changesets
   langtools:   adding file changes
    langtools:   added 4297 changesets with 38693 changes to 
11923 files

    langtools:   updating to branch default
    langtools:   8702 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  hotspot:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/hotspot hotspot

  hotspot:   requesting all changes
  hotspot:   adding changesets
  hotspot:   adding manifests
  jdk:   adding manifests
  hotspot:   adding file changes
  hotspot:   added 13550 changesets with 85505 changes to 
16280 files

  hotspot:   updating to branch default
  hotspot:   9230 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  nashorn:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/nashorn nashorn

  nashorn:   requesting all changes
  nashorn:   adding changesets
  nashorn:   adding manifests
  nashorn:   adding file changes
  nashorn:   added 1990 changesets with 14664 changes to 
4199 files

  nashorn:   updating to branch default
  nashorn:   3310 files updated, 0 files merged, 0 files 
removed, 0 files unresolved

  jdk:   adding file changes
  jdk:   added 17762 changesets with

RE: RFR: JDK-8182733 aarch64 build documentation misleading

2018-09-05 Thread White, Derek

Thanks Magnus!

And sorry, I mistakenly thought I did reply ☹

 - Derek

> -Original Message-
> From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf Of
> Magnus Ihse Bursie
> Sent: Wednesday, September 05, 2018 5:26 AM
> To: David Holmes 
> Cc: build-dev 
> Subject: Re: RFR: JDK-8182733 aarch64 build documentation misleading
> 
> External Email
> 
> A ping on this webrev...
> 
> I've not seen a single thumbs up. :(
> 
> David: The arm64 port is now officially on it's way out. [1] I hope that makes
> you feel confident that the build documentation changes does not have to
> mention it.
> 
> /Magnus
> 
> [1] http://openjdk.java.net/jeps/340
> 
> On 2018-08-03 03:02, David Holmes wrote:
> > On 3/08/2018 10:42 AM, Magnus Ihse Bursie wrote:
> >>
> >>> 2 aug. 2018 kl. 17:38 skrev David Holmes :
> >>>
>  On 3/08/2018 8:23 AM, Andrew Haley wrote:
> > On 08/02/2018 10:44 PM, Magnus Ihse Bursie wrote:
> >
> >>> 2 aug. 2018 kl. 14:07 skrev Andrew Haley :
> >>>
> >>> On 08/02/2018 07:35 AM, David Holmes wrote:
> >>> In theory yes - in practice I don't know if anyone has tried it.
> >>> How
> >>> would you do a native build using the ARM64 sources rather than
> >>> the
> >>> aarch64 sources?
> >>
> >> It's fine.  I used:
> >>
> >> sh  ./configure  --with-native-debug-symbols=internal
> >> --disable-warnings-as-errors --disable-hotspot-gtest
> >> --enable-dtrace=no --with-jtreg=/home/aph/jtreg
> >> --with-boot-jdk=/local/jdk10-pristine/build/linux-aarch64-normal-
> >> server-release/images/jdk/ --enable-precompiled-headers
> >> --with-debug-level=release --with-jvm-features=-aot,-jvmci
> >>
> >> ... but the important part is to disable aot and jvmci.
> >
> > I think what David meant was that it's unclear if it's possible to
> > build the ARM64 port natively, i.e. using --with-cpu-port=arm64,
> > instead of the default --with-cpu-port=aarch64.
>  Sorry, I typo'd the configuration line.
>  In fact, --with-cpu-port=arm64 doesn't work at all because
>  /local/jdk-
> jdk11/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp:70:30:
>  error: ‘src’ was not declared in this scope
>  __ encode_heap_oop(src); and this fails regardless of
>  cross compilation.  So arm(64) does not matter:
>  it's obsolete and does not build.
> >>>
> >>> Broken by:
> >>>
> >>> changeset:   49950:7b916885654d
> >>> user:shade
> >>> date:Wed May 02 19:26:42 2018 +0200
> >>> summary: 8201786: Modularize interpreter GC barriers: leftovers
> >>> for ARM32
> >>>
> >>> Bob flagged the port for removal but not sure what the state of that
> >>> is.
> >>
> >> Maybe it's not worth confounding the build README about the arm64
> >> port, then? That is, just take my doc fix as it is..?
> >
> > Further adjustments will be needed when/if arm64 is removed.
> >
> > I'll leave to those who may actually try to follow these instructions
> > to decide what is best.
> >
> > Thanks,
> > David
> >
> >> /Magnus
> >>
> >>>
> >>> David
> >>> -
> >>>
> >>>
> >>>
> >>

Re: [Newbie question] Strange errors trying to build the JDK

2018-09-05 Thread Kim Barrett

> On Sep 5, 2018, at 5:07 AM, Magnus Ihse Bursie 
>  wrote:
> We do set SHELL to bash for make, so it *should* be running command lines 
> using bash.

Verifying that was why I made this suggestion:

  In your build directory, in ./configure-support/config.log, search for
  the line starting with "SHELL=“.

to make sure configure found bash and is arranging for SHELL to be set 
appropriately.

Re: RFR: JDK-8059019 sdp.conf.template should move from unix to solaris

2018-09-05 Thread Alan Bateman


On 05/09/2018 13:58, Magnus Ihse Bursie wrote:
The file sdp.conf.template is copied only when building for solaris, 
but it resides in the unix source directory.
SDP is legacy now and we should probably think about removing it, esp. 
with the rsocket support in the works.


In the mean time, as the SDP support is compiled into libnet on Linux, 
then we should copy the template in the Linux image too.


-Alan

RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on for
ppc64 s390 and aarch64. This patch intends to turn it on on all arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
 - Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers for
StrictMath:

Function  | before | after
--
sin   | 0m33.382s  | 0m18.731s
cos   | 0m31.562s  | 0m18.796s
tan   | 0m33.657s  | 0m21.093s
atan  | 0m5.714s   | 0m4.902s
log   | 0m6.212s   | 0m4.439s
log10 | 0m7.946s   | 0m5.543s
sqrt  | 0m0.481s   | 0m0.449s
cbrt  | 0m5.295s   | 0m5.214s
tanh  | 0m1.404s   | 0m1.307s
log1p | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2 | 0m8.037s   | 0m5.668s
hypot | 0m2.171s   | 0m2.147s

Thoughts?

Thanks,
Severin

RFR: JDK-8059019 sdp.conf.template should move from unix to solaris

The file sdp.conf.template is copied only when building for solaris, but 
it resides in the unix source directory.


Bug: https://bugs.openjdk.java.net/browse/JDK-8059019
Patch inline:
diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk
+++ b/make/copy/Copy-java.base.gmk
@@ -185,7 +185,7 @@

 ifeq ($(OPENJDK_TARGET_OS), solaris)
   $(eval $(call SetupCopyFiles, COPY_SDP_CONF, \
-  FILES := 
$(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/sdp/sdp.conf.template, 
\
+  FILES := 
$(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/conf/sdp/sdp.conf.template, \

   DEST := $(CONF_DST_DIR)/sdp, \
   ))

diff --git a/src/java.base/unix/conf/sdp/sdp.conf.template 
b/src/java.base/solaris/conf/sdp/sdp.conf.template

rename from src/java.base/unix/conf/sdp/sdp.conf.template
rename to src/java.base/solaris/conf/sdp/sdp.conf.template

/Magnus

RFR: JDK-8056217 Remove awt_makecube.cpp

As per the discussion in JDK-8056217, the file awt_makecube.cpp (which 
is not compiler nor used) should be removed.


Bug: https://bugs.openjdk.java.net/browse/JDK-8056217

Change:
$ hg status
R src/java.desktop/windows/native/common/awt_makecube.cpp

/Magnus

RFR: JDK-8081858 make dist-clean does not delete all log files

"make dist-clean" leaves build.log and configure.log behind, as well as 
the rotated .old files.


Bug: https://bugs.openjdk.java.net/browse/JDK-8081858
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8081858-fix-dist-clean/webrev.01


/Magnus

RFR: JDK-8200609 Proper fix for mapfile removal for libjsig

When I removed (mostly) all mapfiles for the JDK libraries, building of 
libjsig started failing on Solaris, and that part was backed out.


Here's a new, and improved solution to remove the mapfile for libjsig, 
even on Solaris.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200609
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01


/Magnus

Re: RFR 8210318: idea.sh script doesn't work on Mac


On 2018-09-05 13:42, Maurizio Cimadamore wrote:
Here's the modified webrev - as suggested, I replaced /tmp/replacement 
with $1.tmp


http://cr.openjdk.java.net/~mcimadamore/8210318_v2/


Looks good to me.

/Magnus



Thanks
Maurizio


On 04/09/18 18:50, Erik Joelsson wrote:

Hello,

$TARGET was just pseudo code. In your case it's $1.tmp.

/Erik


On 2018-09-04 10:34, Maurizio Cimadamore wrote:

Hi Erik,
would $TARGET be set by make?

Maurizio


On 04/09/18 16:55, Erik Joelsson wrote:

Hello,

When choosing a temp file in the build, we avoid using /tmp 
whenever possible. A common pattern is instead to write to 
$TARGET.tmp and then mv that to $TARGET. Though unlikely to cause 
an issue, /tmp/replacement is a global location which is 
potentially risky (file permissions, concurrent execution etc).


Otherwise looks good.

/Erik

On 2018-09-03 05:39, Maurizio Cimadamore wrote:

Hi,
following the latest updates to the idea.sh script, Mac users 
reported issues - mostly having to do with usage of 'sed' - more 
specifically:


* sed -i option is not portable - it has different formats in Mac 
vs. Linux. This patch does without -i, by moving the replaced file 
onto a temporary file, then moving such file on top of the 
template file in a subsequent step. This should be more robust.


* sed doesn't like newlines in replaced text in Mac. I've thus 
omitted the newline from the SOURCE template - as that was mostly 
cosmetic.


Thanks for Michael McMahon to report (and figure out how to deal 
with) these issues, and to Alan Bateman for testing the patch.


I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location 
in the various run configuration.


Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210318/

Cheers
Maurizio

Re: RFR 8210318: idea.sh script doesn't work on Mac

2018-09-05 Thread Maurizio Cimadamore

Here's the modified webrev - as suggested, I replaced /tmp/replacement 
with $1.tmp


http://cr.openjdk.java.net/~mcimadamore/8210318_v2/

Thanks
Maurizio


On 04/09/18 18:50, Erik Joelsson wrote:

Hello,

$TARGET was just pseudo code. In your case it's $1.tmp.

/Erik


On 2018-09-04 10:34, Maurizio Cimadamore wrote:

Hi Erik,
would $TARGET be set by make?

Maurizio


On 04/09/18 16:55, Erik Joelsson wrote:

Hello,

When choosing a temp file in the build, we avoid using /tmp whenever 
possible. A common pattern is instead to write to $TARGET.tmp and 
then mv that to $TARGET. Though unlikely to cause an issue, 
/tmp/replacement is a global location which is potentially risky 
(file permissions, concurrent execution etc).


Otherwise looks good.

/Erik

On 2018-09-03 05:39, Maurizio Cimadamore wrote:

Hi,
following the latest updates to the idea.sh script, Mac users 
reported issues - mostly having to do with usage of 'sed' - more 
specifically:


* sed -i option is not portable - it has different formats in Mac 
vs. Linux. This patch does without -i, by moving the replaced file 
onto a temporary file, then moving such file on top of the template 
file in a subsequent step. This should be more robust.


* sed doesn't like newlines in replaced text in Mac. I've thus 
omitted the newline from the SOURCE template - as that was mostly 
cosmetic.


Thanks for Michael McMahon to report (and figure out how to deal 
with) these issues, and to Alan Bateman for testing the patch.


I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location 
in the various run configuration.


Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210318/

Cheers
Maurizio

Re: RFR: JDK-8182733 aarch64 build documentation misleading


On 5/09/2018 7:25 PM, Magnus Ihse Bursie wrote:

A ping on this webrev...

I've not seen a single thumbs up. :(

David: The arm64 port is now officially on it's way out. [1] I hope that 
makes you feel confident that the build documentation changes does not 
have to mention it.


Yes.

Thanks,
David


/Magnus

[1] http://openjdk.java.net/jeps/340

On 2018-08-03 03:02, David Holmes wrote:

On 3/08/2018 10:42 AM, Magnus Ihse Bursie wrote:



2 aug. 2018 kl. 17:38 skrev David Holmes :


On 3/08/2018 8:23 AM, Andrew Haley wrote:

On 08/02/2018 10:44 PM, Magnus Ihse Bursie wrote:


2 aug. 2018 kl. 14:07 skrev Andrew Haley :

On 08/02/2018 07:35 AM, David Holmes wrote:
In theory yes - in practice I don't know if anyone has tried it. 
How

would you do a native build using the ARM64 sources rather than the
aarch64 sources?


It's fine.  I used:

sh  ./configure  --with-native-debug-symbols=internal 
--disable-warnings-as-errors --disable-hotspot-gtest 
--enable-dtrace=no --with-jtreg=/home/aph/jtreg 
--with-boot-jdk=/local/jdk10-pristine/build/linux-aarch64-normal-server-release/images/jdk/ 
--enable-precompiled-headers --with-debug-level=release 
--with-jvm-features=-aot,-jvmci


... but the important part is to disable aot and jvmci.


I think what David meant was that it's unclear if it's possible to 
build the ARM64 port natively, i.e. using --with-cpu-port=arm64, 
instead of the default --with-cpu-port=aarch64.

Sorry, I typo'd the configuration line.
In fact, --with-cpu-port=arm64 doesn't work at all because
/local/jdk-jdk11/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp:70:30: 
error: ‘src’ was not declared in this scope

    __ encode_heap_oop(src);
and this fails regardless of cross compilation.  So arm(64) does 
not matter:

it's obsolete and does not build.


Broken by:

changeset:   49950:7b916885654d
user:    shade
date:    Wed May 02 19:26:42 2018 +0200
summary: 8201786: Modularize interpreter GC barriers: leftovers 
for ARM32


Bob flagged the port for removal but not sure what the state of that 
is.


Maybe it's not worth confounding the build README about the arm64 
port, then? That is, just take my doc fix as it is..?


Further adjustments will be needed when/if arm64 is removed.

I'll leave to those who may actually try to follow these instructions 
to decide what is best.


Thanks,
David


/Magnus



David
-

RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning

2018-09-05 Thread Baesken, Matthias

Hello,  when compilingjdk/jdk   on Windows,  (with VS2017 update level 15.8 
and not disabling warnings as errors )
I came across  this  warning   leading to build error :

C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
error C2220: warning treated as error - no 'object' file generated
C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
warning C4305: 'argument': truncation from 'const intx' to 'double'

Would have been helpful  to have a compiler flag set  that really   ***shows  
the code***  leading to the warning/error  (because it comes from heavy macro 
expansion).


The following  CR   ,   Reported by 
ralf.schmel...@sap.com  , fixes the issue  :

The flag -XX:EpsilonTLABElasticity (epsilon_globals.hpp, line 77) expects a 
double value, but uses max_intx in the allowed range.
This leads to a truncation warning in the Windows build. If the value should 
only be guaranteed to be >= 1, then DBL_MAX should have been used instead.


Webrev/bug :

http://cr.openjdk.java.net/~mbaesken/webrevs/8209942/

https://bugs.openjdk.java.net/browse/JDK-8209942


Please review .




Thanks, Matthias

Re: RFR: JDK-8182733 aarch64 build documentation misleading


On 2018-09-05 11:33, Aleksey Shipilev wrote:

On 09/05/2018 11:25 AM, Magnus Ihse Bursie wrote:

A ping on this webrev...

Oh, I thought is was done. Had to walk around the thread to look for the link. 
This webrev?

   Bug: https://bugs.openjdk.java.net/browse/JDK-8182733
   WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8182733-update-aarch64-build-docs/webrev.01


Yes.



I've not seen a single thumbs up. :(

Changes look good to me.

Thanks!

/Magnus


-Aleksey

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option


Hi Andrew,

Thanks for your response!

I just quote it from here:

http://mail.openjdk.java.net/pipermail/build-dev/2016-July/017464.html

I spotted that jsig is just a single C file and so doesn't
need the -std flag. In fact, it complains about it:

Compiling jsig.c (for libjsig.so)
( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 
-std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\
MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o 
/home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\
rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > 
>(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\
g.o.log) 2> >(/usr/bin/tee 
/home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( 
exitcode=$? && /bin/cp /home/and\
rew/builder/dev/hotspot/libjsig/objs/jsig.o.log 
/home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\

.log && exit $exitcode ) ) && wait )
cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ 
but not for C


It is still able to reproducible the warning for OpenJDK8 mips64el with 
GCC and LLVM toolchains.  And gcc treat it as warning,  so it is often 
be ignored,  but clang treat it as error.

- 8<  8<  8<  8<  8<  8< ---

Because CXXSTD_CXXFLAG="-std=gnu++98",  such flag might be effect 
others,  so workaround for LLVM toolchain:

diff -r 1a87e769fb7f hotspot/make/linux/makefiles/jsig.make
--- a/hotspot/make/linux/makefiles/jsig.makeMon Sep 03 18:02:35 2018 
+0800
+++ b/hotspot/make/linux/makefiles/jsig.makeWed Sep 05 15:53:22 2018 
+0800

@@ -54,7 +54,7 @@
 $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE)
 @echo Making signal interposition lib...
 $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \
- $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) 
$(EXTRA_CFLAGS) -o $@ $< -ldl
+ $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) 
-fintegrated-as -o $@ $< -ldl

 ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
 $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJSIG_DEBUGINFO)
 $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJSIG_DEBUGINFO) $@
diff -r 1a87e769fb7f hotspot/make/linux/makefiles/saproc.make
--- a/hotspot/make/linux/makefiles/saproc.makeMon Sep 03 18:02:35 
2018 +0800
+++ b/hotspot/make/linux/makefiles/saproc.makeWed Sep 05 15:53:22 
2018 +0800

@@ -118,7 +118,7 @@
$(SASRCFILES) \
$(SA_LFLAGS) \
$(SA_DEBUG_CFLAGS) \
-   $(EXTRA_CFLAGS) \
+ -fintegrated-as  \
-o $@ \
-lthread_db
 endif

Please give me some suggestion,  thanks a lot!

--
Regards,
Leslie Zhai

Re: RFR: JDK-8182733 aarch64 build documentation misleading

2018-09-05 Thread Aleksey Shipilev

On 09/05/2018 11:25 AM, Magnus Ihse Bursie wrote:
> A ping on this webrev...

Oh, I thought is was done. Had to walk around the thread to look for the link. 
This webrev?

  Bug: https://bugs.openjdk.java.net/browse/JDK-8182733
  WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8182733-update-aarch64-build-docs/webrev.01

> I've not seen a single thumbs up. :(

Changes look good to me.

-Aleksey

Re: RFR: JDK-8182733 aarch64 build documentation misleading


A ping on this webrev...

I've not seen a single thumbs up. :(

David: The arm64 port is now officially on it's way out. [1] I hope that 
makes you feel confident that the build documentation changes does not 
have to mention it.


/Magnus

[1] http://openjdk.java.net/jeps/340

On 2018-08-03 03:02, David Holmes wrote:

On 3/08/2018 10:42 AM, Magnus Ihse Bursie wrote:



2 aug. 2018 kl. 17:38 skrev David Holmes :


On 3/08/2018 8:23 AM, Andrew Haley wrote:

On 08/02/2018 10:44 PM, Magnus Ihse Bursie wrote:


2 aug. 2018 kl. 14:07 skrev Andrew Haley :

On 08/02/2018 07:35 AM, David Holmes wrote:
In theory yes - in practice I don't know if anyone has tried it. 
How

would you do a native build using the ARM64 sources rather than the
aarch64 sources?


It's fine.  I used:

sh  ./configure  --with-native-debug-symbols=internal 
--disable-warnings-as-errors --disable-hotspot-gtest 
--enable-dtrace=no --with-jtreg=/home/aph/jtreg 
--with-boot-jdk=/local/jdk10-pristine/build/linux-aarch64-normal-server-release/images/jdk/ 
--enable-precompiled-headers --with-debug-level=release 
--with-jvm-features=-aot,-jvmci


... but the important part is to disable aot and jvmci.


I think what David meant was that it's unclear if it's possible to 
build the ARM64 port natively, i.e. using --with-cpu-port=arm64, 
instead of the default --with-cpu-port=aarch64.

Sorry, I typo'd the configuration line.
In fact, --with-cpu-port=arm64 doesn't work at all because
/local/jdk-jdk11/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp:70:30: 
error: ‘src’ was not declared in this scope

    __ encode_heap_oop(src);
and this fails regardless of cross compilation.  So arm(64) does 
not matter:

it's obsolete and does not build.


Broken by:

changeset:   49950:7b916885654d
user:    shade
date:    Wed May 02 19:26:42 2018 +0200
summary: 8201786: Modularize interpreter GC barriers: leftovers 
for ARM32


Bob flagged the port for removal but not sure what the state of that 
is.


Maybe it's not worth confounding the build README about the arm64 
port, then? That is, just take my doc fix as it is..?


Further adjustments will be needed when/if arm64 is removed.

I'll leave to those who may actually try to follow these instructions 
to decide what is best.


Thanks,
David


/Magnus



David
-

Re: [Newbie question] Strange errors trying to build the JDK


On 2018-09-05 09:49, Zambonifofex wrote:

Hello. It seems to work fine on Bash. On Fish, I get the following error:

 fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
 cd 
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs
&& \

^

Fish uses the ‘and’ command
 instead of
Bash’s ‘&&’ operator.


Okay... So what happens if you run the command in bash, which is what 
make will be using?


We do set SHELL to bash for make, so it *should* be running command 
lines using bash.


But just to be sure, please test running the make command from bash as well.

/Magnus



On Wed, Sep 5, 2018 at 4:35 AM Magnus Ihse Bursie
 wrote:

On 2018-08-22 17:45, Ioi Lam wrote:

Looks like it's this command that failed:


cd 
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs
 && \
   /usr/bin/nm --defined-only *.o | /usr/bin/nawk '{ if ($3 ~ 
/^_ZTV|^gHotSpotVM|^UseSharedSpaces$|^_ZN9Arguments17SharedArchivePathE$/) 
print $3; }' | /usr/bin/sort -u


Try cut-and-paste that into a terminal and see what error it reports,


Zambonifofex,

This is very good advice. You should try it.

If it does not return a long list of symbols, try breaking it down in parts to 
see if you can figure out where it fails.

/Magnus


Thanks

- Ioi


On 8/21/18 11:18 PM, David Holmes wrote:

Interesting - there is no actual error report in the log. Only this:

lib/JvmMapfile.gmk:141: recipe for target 
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
 failed

Looking at the gmk file we have:

$(JVM_OUTPUTDIR)/symbols-objects: $(BUILD_LIBJVM_ALL_OBJS)
 $(call LogInfo, Generating symbol list from object files)
 $(CD) $(JVM_OUTPUTDIR)/objs && \
   $(DUMP_SYMBOLS_CMD) | $(NAWK) $(FILTER_SYMBOLS_AWK_SCRIPT) | $(SORT) -u 
> $@

I'd have to suspect one of the command variables is not set. I suspect the 
actual error text may be redirected to the symbols-objects file, but 
unfortunately that has been deleted by 'make'.

Check the generated spec.gmk file for the value of DUMP_SYMBOLS_CMD and NAWK.

David

On 22/08/2018 1:45 PM, Zambonifofex wrote:

Hello.

I’ve run the following commands (using the Fish shell):

  /home/zambonifofex/jdk/ $ make hotspot > ~/log.txt ^&1
  /home/zambonifofex/jdk/ $ env LOG=trace make hotspot > ~/log-trace.txt ^&1
  /home/zambonifofex/jdk/ $

I’ll attach the generated files in this email.

Thanks once again.
On Tue, Aug 21, 2018 at 8:51 PM Gustavo Romero
 wrote:


Hi,

On 08/21/2018 08:00 PM, David Holmes wrote:

Hi,

You need to search further up the build log to try and find the actual error 
that occurred when building hotspot.

Run "make hotspot" and it should be easier to see.


In addition to David's suggestion you can also add before the command 
LOG=trace, like:

$ LOG=trace make hotspot

to spot the executed commands in the build process.


Regards,
Gustavo

David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

   /home/zambonifofex/jdk/ $ hg id
   2e91d927e00c+ tip
   /home/zambonifofex/jdk/ $ make images
   Building target 'images' in configuration
'linux-x86_64-normal-server-release'
   lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
failed
   make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]
Error 1
   make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
   make[2]: *** [hotspot-server-libs] Error 1
   make[2]: *** Waiting for unfinished jobs

   ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit

Re: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

On Wed, 2018-09-05 at 07:38 +1000, David Holmes wrote:
> On 5/09/2018 7:29 AM, Erik Joelsson wrote:
> > On 2018-09-04 14:06, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > On 5/09/2018 1:36 AM, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Could I please get reviews of this JDK 8-only change?
> > > > 
> > > > The issue at hand is that the JDK 8 build seems to be inconsistent with
> > > > later JDK builds (9+). When somebody passes
> > > > --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM
> > > > will get compiled with -O3 for a release type build. Not so on JDK 8.
> > > > It gets compiled with -O2. The reason we are passing extra C flags via
> > > > configure is to: a) get distro-wide optimization done b) allow for
> > > > hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag,
> > > > libjsig, libsaproc will get compiled with no optimization. That's what
> > > > I'd like to fix. The proposed patch allows one to force -O2 for the JVM
> > > > via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2
> > > > allows one to get hotspot libraries optimized with -O2 and better.
> > > > Thoughts?
> > > 
> > > I don't understand the motivation for this change. Compatibility with 
> > > future versions is not a usual compatibility we care about. I'd also 
> > > argue the behaviour in 8 seems more correct. If I set an extra cflag I 
> > > expect it to be applied to all compilations - cross-compilation would 
> > > be broken if that were not the case. I don't see why -On should be 
> > > treated any differently.
> > > 
> > 
> > I do agree with you, sort of. All user added flags are applied 
> > everywhere. The reason the optimization isn't overridden is because of 
> > the order the flags are applied on the command line. In JDK 9 (and in 8 
> > for JDK libs) we apply optimization flags after the custom flags from 
> > the user. (For Hotspot in 8 it seems the custom flags are added after 
> > the optimization flags.) IIRC we did this intentionally in the "new 
> > build" with the reasoning that we are pretty particular with the 
> > optimization flags in many cases so a global override is probably not a 
> > good idea.
> > 
> > The suggested patch, filtering specific -O flags from the user supplied 
> > flags does not look good to me. I would however be ok with changing the 
> > ordering of flags for libjvm so that the same behavior as in 9 and later 
> > (and as for JDK libs in 8) is achieved.
> 
> Okay - but such a change should be considered an enhancement request, 
> not a bug fix, and must then go through the enhancement request process 
> for 8u. My concern is that this may fix Severin's issue but may break 
> others who do custom builds of 8u code. The 8u maintainers would have to 
> make the decision to accept this change or not.

Fair enough. I'll get this process started then.

Thanks,
Severin

> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
> > > > webrev: 
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/
> > > > 
> > > > Thanks,
> > > > Severin
> > > >

Re: [Newbie question] Strange errors trying to build the JDK

2018-09-05 Thread Zambonifofex

Hello. It seems to work fine on Bash. On Fish, I get the following error:

fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
cd 
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs
&& \

   ^

Fish uses the ‘and’ command
 instead of
Bash’s ‘&&’ operator.
On Wed, Sep 5, 2018 at 4:35 AM Magnus Ihse Bursie
 wrote:
>
> On 2018-08-22 17:45, Ioi Lam wrote:
>
> Looks like it's this command that failed:
>
>
> cd 
> /home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs
>  && \
>   /usr/bin/nm --defined-only *.o | /usr/bin/nawk '{ if ($3 ~ 
> /^_ZTV|^gHotSpotVM|^UseSharedSpaces$|^_ZN9Arguments17SharedArchivePathE$/) 
> print $3; }' | /usr/bin/sort -u
>
>
> Try cut-and-paste that into a terminal and see what error it reports,
>
>
> Zambonifofex,
>
> This is very good advice. You should try it.
>
> If it does not return a long list of symbols, try breaking it down in parts 
> to see if you can figure out where it fails.
>
> /Magnus
>
>
> Thanks
>
> - Ioi
>
>
> On 8/21/18 11:18 PM, David Holmes wrote:
>
> Interesting - there is no actual error report in the log. Only this:
>
> lib/JvmMapfile.gmk:141: recipe for target 
> '/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
>  failed
>
> Looking at the gmk file we have:
>
> $(JVM_OUTPUTDIR)/symbols-objects: $(BUILD_LIBJVM_ALL_OBJS)
> $(call LogInfo, Generating symbol list from object files)
> $(CD) $(JVM_OUTPUTDIR)/objs && \
>   $(DUMP_SYMBOLS_CMD) | $(NAWK) $(FILTER_SYMBOLS_AWK_SCRIPT) | $(SORT) -u 
> > $@
>
> I'd have to suspect one of the command variables is not set. I suspect the 
> actual error text may be redirected to the symbols-objects file, but 
> unfortunately that has been deleted by 'make'.
>
> Check the generated spec.gmk file for the value of DUMP_SYMBOLS_CMD and NAWK.
>
> David
>
> On 22/08/2018 1:45 PM, Zambonifofex wrote:
>
> Hello.
>
> I’ve run the following commands (using the Fish shell):
>
>  /home/zambonifofex/jdk/ $ make hotspot > ~/log.txt ^&1
>  /home/zambonifofex/jdk/ $ env LOG=trace make hotspot > ~/log-trace.txt 
> ^&1
>  /home/zambonifofex/jdk/ $
>
> I’ll attach the generated files in this email.
>
> Thanks once again.
> On Tue, Aug 21, 2018 at 8:51 PM Gustavo Romero
>  wrote:
>
>
> Hi,
>
> On 08/21/2018 08:00 PM, David Holmes wrote:
>
> Hi,
>
> You need to search further up the build log to try and find the actual error 
> that occurred when building hotspot.
>
> Run "make hotspot" and it should be easier to see.
>
>
> In addition to David's suggestion you can also add before the command 
> LOG=trace, like:
>
> $ LOG=trace make hotspot
>
> to spot the executed commands in the build process.
>
>
> Regards,
> Gustavo
>
> David
>
> On 20/08/2018 11:53 AM, Zambonifofex wrote:
>
> Hello, everyone.
>
> I am new to collaborating to the JDK, so sorry if this question is too
> newbie‐ish.
>
> I have recently been affected by a minor bug in the ‘java.desktop’
> module on Linux. I figured I’d try to fix it by myself, so I followed
> the steps in the “How to Contribute” page, the “Building” page, as
> well as some more that I could find online.
>
> The bug number is ‘7162479’. The bug is that it calling
> ‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
> ‘setResizable(false)’ has been called on the same ‘JFrame’.
>
> When I tried to build the JDK with ‘make images’, after getting a
> couple errors related to the changes I made and fixing them, I started
> to face a strange error that was not related to the changes I made at
> all.
>
> Here is the log I get when trying to run ‘make images’ currently, as
> well as the output of ‘hg id’, if that’s of any help (where
> ‘/home/zambonifofex/jdk $’ is the prompt):
>
>   /home/zambonifofex/jdk/ $ hg id
>   2e91d927e00c+ tip
>   /home/zambonifofex/jdk/ $ make images
>   Building target 'images' in configuration
> 'linux-x86_64-normal-server-release'
>   lib/JvmMapfile.gmk:141: recipe for target
> '/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
> failed
>   make[3]: ***
> [/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]
> Error 1
>   make[3]: *** Deleting file
> '/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'
>   make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
>   make[2]: *** [hotspot-server-libs] Error 1
>   make[2]: *** Waiting for unfinished jobs
>
>   ERROR: Build failed for target 'images' in configuration
> 'linux-x86_64-normal-server-release' (exit code 2)
>
>   === Make failed targets repeated here ===
>   lib/JvmMapfile.gmk:141: recipe

Re: [Newbie question] Strange errors trying to build the JDK


On 2018-08-22 17:45, Ioi Lam wrote:

Looks like it's this command that failed:


cd 
/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs 
&& \
  /usr/bin/nm --defined-only *.o | /usr/bin/nawk '{ if ($3 ~ 
/^_ZTV|^gHotSpotVM|^UseSharedSpaces$|^_ZN9Arguments17SharedArchivePathE$/) 
print $3; }' | /usr/bin/sort -u



Try cut-and-paste that into a terminal and see what error it reports,


Zambonifofex,

This is very good advice. You should try it.

If it does not return a long list of symbols, try breaking it down in 
parts to see if you can figure out where it fails.


/Magnus



Thanks

- Ioi


On 8/21/18 11:18 PM, David Holmes wrote:

Interesting - there is no actual error report in the log. Only this:

lib/JvmMapfile.gmk:141: recipe for target 
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 
failed


Looking at the gmk file we have:

$(JVM_OUTPUTDIR)/symbols-objects: $(BUILD_LIBJVM_ALL_OBJS)
$(call LogInfo, Generating symbol list from object files)
$(CD) $(JVM_OUTPUTDIR)/objs && \
  $(DUMP_SYMBOLS_CMD) | $(NAWK) $(FILTER_SYMBOLS_AWK_SCRIPT) | 
$(SORT) -u > $@


I'd have to suspect one of the command variables is not set. I 
suspect the actual error text may be redirected to the 
symbols-objects file, but unfortunately that has been deleted by 'make'.


Check the generated spec.gmk file for the value of DUMP_SYMBOLS_CMD 
and NAWK.


David

On 22/08/2018 1:45 PM, Zambonifofex wrote:

Hello.

I’ve run the following commands (using the Fish shell):

 /home/zambonifofex/jdk/ $ make hotspot > ~/log.txt ^&1
 /home/zambonifofex/jdk/ $ env LOG=trace make hotspot > 
~/log-trace.txt ^&1

 /home/zambonifofex/jdk/ $

I’ll attach the generated files in this email.

Thanks once again.
On Tue, Aug 21, 2018 at 8:51 PM Gustavo Romero
 wrote:


Hi,

On 08/21/2018 08:00 PM, David Holmes wrote:

Hi,

You need to search further up the build log to try and find the 
actual error that occurred when building hotspot.


Run "make hotspot" and it should be easier to see.


In addition to David's suggestion you can also add before the 
command LOG=trace, like:


$ LOG=trace make hotspot

to spot the executed commands in the build process.


Regards,
Gustavo


David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question 
is too

newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I 
followed

the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I 
started
to face a strange error that was not related to the changes I 
made at

all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

  /home/zambonifofex/jdk/ $ hg id
  2e91d927e00c+ tip
  /home/zambonifofex/jdk/ $ make images
  Building target 'images' in configuration
'linux-x86_64-normal-server-release'
  lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 


failed
  make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects] 


Error 1
  make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 

  make/Main.gmk:257: recipe for target 'hotspot-server-libs' 
failed

  make[2]: *** [hotspot-server-libs] Error 1
  make[2]: *** Waiting for unfinished jobs

  ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

  === Make failed targets repeated here ===
  lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects' 


failed
  make/Main.gmk:257: recipe for target 'hotspot-server-libs' 
failed

  === End of repeated output ===

  Hint: Try searching the build log for the name of the first 
failed target.

  Hint: See doc/building.html#troubleshooting for assistance.

  /home/zambonifofex/jdk/make/Init.gmk:300: recipe for target 
'main' failed

  make[1]: *** [main] Error 1
  /home/zambonifofex/jdk/make/Init.gmk:186: recipe for target 
'images' failed

  make: *** [images] Error 2
  /home/zambonifofex/jdk/ $

Any help would be appreciated.

Re: [Newbie question] Strange errors trying to build the JDK


On 2018-09-04 04:56, Kim Barrett wrote:

On Aug 21, 2018, at 11:45 PM, Zambonifofex  wrote:

Hello.

I’ve run the following commands (using the Fish shell):

It might be nothing, but this caught my eye. Are you using fish as
your shell when trying to configure / build? Maybe that doesn't work?
That should not be a problem, as long as he has bash installed. (And if 
he didn't, configure would have complained). That being said, we have 
not actually *tested* building using a non-bash shell for a long time...


/Magnus


In your build directory, in ./configure-support/config.log, search for
the line starting with "SHELL=".

Re: [Newbie question] Strange errors trying to build the JDK

On 2018-08-22 02:24, Ioi Lam wrote:
I am not sure if this is documented anywhere. Try searching for "Error
2". It usually will tell you where the error is.

There's an entire section named "Locating the Source of the Error" in
doc/building.md. It's worth reading to be proficient in finding and
fixing build issues quickly.

/Magnus

Thanks
- Ioi

On 8/21/18 4:51 PM, Gustavo Romero wrote:

Hi,

On 08/21/2018 08:00 PM, David Holmes wrote:

Hi,

You need to search further up the build log to try and find the
actual error that occurred when building hotspot.

Run "make hotspot" and it should be easier to see.

In addition to David's suggestion you can also add before the command
LOG=trace, like:

$ LOG=trace make hotspot

to spot the executed commands in the build process.

Regards,
Gustavo

David

On 20/08/2018 11:53 AM, Zambonifofex wrote:

Hello, everyone.

I am new to collaborating to the JDK, so sorry if this question is too
newbie‐ish.

I have recently been affected by a minor bug in the ‘java.desktop’
module on Linux. I figured I’d try to fix it by myself, so I followed
the steps in the “How to Contribute” page, the “Building” page, as
well as some more that I could find online.

The bug number is ‘7162479’. The bug is that it calling
‘setLocationByPlatform(true)’ on a ‘JFrame’ will not work if
‘setResizable(false)’ has been called on the same ‘JFrame’.

When I tried to build the JDK with ‘make images’, after getting a
couple errors related to the changes I made and fixing them, I started
to face a strange error that was not related to the changes I made at
all.

Here is the log I get when trying to run ‘make images’ currently, as
well as the output of ‘hg id’, if that’s of any help (where
‘/home/zambonifofex/jdk $’ is the prompt):

/home/zambonifofex/jdk/ $ hg id
2e91d927e00c+ tip
/home/zambonifofex/jdk/ $ make images
Building target 'images' in configuration
'linux-x86_64-normal-server-release'
lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'

failed
make[3]: ***
[/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects]

Error 1
make[3]: *** Deleting file
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'

make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
make[2]: *** [hotspot-server-libs] Error 1
make[2]: *** Waiting for unfinished jobs

ERROR: Build failed for target 'images' in configuration
'linux-x86_64-normal-server-release' (exit code 2)

=== Make failed targets repeated here ===
lib/JvmMapfile.gmk:141: recipe for target
'/home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/symbols-objects'

failed
make/Main.gmk:257: recipe for target 'hotspot-server-libs' failed
=== End of repeated output ===

Hint: Try searching the build log for the name of the first
failed target.

Hint: See doc/building.html#troubleshooting for assistance.

/home/zambonifofex/jdk/make/Init.gmk:300: recipe for target
'main' failed

make[1]: *** [main] Error 1
/home/zambonifofex/jdk/make/Init.gmk:186: recipe for target
'images' failed

make: *** [images] Error 2
/home/zambonifofex/jdk/ $

Any help would be appreciated. Thanks in advance.

Re: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target

2018-09-05 Thread John Paul Adrian Glaubitz

You’re right, sorry. I haven’t been around OpenJDK for some weeks and forgot 
about posting to build-dev when posting.

I will push in around 2-3 hours, currently on a train.

Adrian

> On Sep 5, 2018, at 9:05 AM, Magnus Ihse Bursie 
>  wrote:
> 
>> On 2018-09-04 23:29, David Holmes wrote:
>> Hi Adrian, 
>> 
>> All changes that touch the build system must be reviewed by build-dev - now 
>> cc'd. 
> This has been discussed at some length in build-dev. But I agree, it's good 
> that also the actual RFR is cc:ed here.
> 
> The patch, unsurprisingly, LGTM.
> 
> /Magnus
> 
>> 
>> These changes seem reasonable, though I don't like adding changes in source 
>> code for such an obscure (and unsupported!) platform. 
>> 
>> David 
>> 
>>> On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote: 
>>> Hi! 
>>> 
>>> This rather small change adds build support for the x86_64-linux-gnux32 
>>> target. x32 is a variant of the x86_64 ABI with 64-bit registers and amd64 
>>> instruction set but 32-bit pointers [1]. 
>>> 
>>> One of the Linux distributions supporting x32 is Debian, see [2]. The 
>>> port is not official, but the large majority of packages build fine 
>>> and the toolchain is in good shape. Another distribution supporting 
>>> x32 is Gentoo. 
>>> 
>>> Please review the change in [3]. I have changed the original patch 
>>> a bit that Debian uses downstream to make the changes more consistent 
>>> and cleaner. 
>>> 
>>> Thanks, 
>>> Adrian 
>>> 
 [1] https://en.wikipedia.org/wiki/X32_ABI 
 [2] http://debian-x32.org/ 
 [2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/ 
>>> 
>

Re: Compiling OpenJDK8 with LLVM for mips64el


Hi Magnus,

Thanks for your kind response!


在 2018年09月05日 14:40, Magnus Ihse Bursie 写道:

On 2018-09-05 06:03, Leslie Zhai wrote:

Hi all,

Thanks for Aleksandar Beserminji great job:

https://reviews.llvm.org/D50437

It is not easy to reproduce the LLVMBUG-38221[1] by building 
OpenJDK8,  it needs some workaround


https://raw.githubusercontent.com/xiangzhai/jdk8u-dev/master/Workaround-compile-with-llvm.patch 



Hi Leslie,

Great to see that this combination works as well with just so little 
tweaking!


However, since the mips64 port is not in upstream (in fact, it's 
currently not even an OpenJDK project), I think this patch better goes 
to the mips-port list.
Sorry for my poor English!  Because Aleksandar had implemented the 
missing instructions for LLVM Mips target.  And he asked me how to build 
OpenJDK8 for testing https://bugs.llvm.org/show_bug.cgi?id=38221#c9


So I just tested for him, thanks for his great job again!



/Magnus



LLVM toolchain[2] is just able to compile OpenJDK8 for mips64el now:

http://hg.loongnix.org/

1. https://bugs.llvm.org/show_bug.cgi?id=38221#c10

2. $ clang -v
Loongson clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 
56fc90882612ab774dae937ca8d997c59364f7f8) 
(g...@github.com:llvm-mirror/llvm.git 
3419b04cf0c0a57577865f0d17fefb205deed048) (based on LLVM 8.0.0svn)

Target: mips64el-redhat-linux
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: 
/usr/bin/../lib/gcc/mips64el-redhat-linux/4.9.3
Found candidate GCC installation: 
/usr/lib/gcc/mips64el-redhat-linux/4.9.3
Selected GCC installation: 
/usr/bin/../lib/gcc/mips64el-redhat-linux/4.9.3

Candidate multilib: .;
Selected multilib: .;





--
Regards,
Leslie Zhai

Re: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot


On 2018-09-04 17:49, Erik Joelsson wrote:

On 2018-09-03 00:19, David Holmes wrote:

On 30/08/2018 10:36 PM, Magnus Ihse Bursie wrote:

Hi folks,

This bug report goes all the way back to 2008. :-) So instead of 
just letting it go on to it's second decade of existence, I went 
about and fixed it.


Ummm but now it's called Oracle Developer Studio.

Yes, we are aware of that, so ideally we should rename it all over. 


Or maybe we shouldn't. If so, we should also rename "macosx" to "macos".

Alternatively, we can accept that the best we can do is to have a name 
that's not ambiguous, clearly states what it is about, is not misleading 
(that was one of the main complaints about the old "sparcWorks"; it was 
not about sparc, it was about solaris). And hope that marketing let us 
keep our good names in sync with the marketing names used, as long as 
possible.


/Magnus

This bug was about unification however, and now it's at least unified. 
One could also note that the version we are currently using (12.4) was 
still called Solaris Studio. The rename happened in later versions.


/Erik

David

By now, not many references to sparcWorks exists anymore, so this is 
almost trivial.


I've verified by grep that no more "sparcworks" are present in the 
repo, neither in hotspot nor anywhere else.


Bug: https://bugs.openjdk.java.net/browse/JDK-6657100
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 



/Magnus

Re: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target


On 2018-09-04 23:29, David Holmes wrote:

Hi Adrian,

All changes that touch the build system must be reviewed by build-dev 
- now cc'd.
This has been discussed at some length in build-dev. But I agree, it's 
good that also the actual RFR is cc:ed here.


The patch, unsurprisingly, LGTM.

/Magnus



These changes seem reasonable, though I don't like adding changes in 
source code for such an obscure (and unsupported!) platform.


David

On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote:

Hi!

This rather small change adds build support for the x86_64-linux-gnux32
target. x32 is a variant of the x86_64 ABI with 64-bit registers and 
amd64

instruction set but 32-bit pointers [1].

One of the Linux distributions supporting x32 is Debian, see [2]. The
port is not official, but the large majority of packages build fine
and the toolchain is in good shape. Another distribution supporting
x32 is Gentoo.

Please review the change in [3]. I have changed the original patch
a bit that Debian uses downstream to make the changes more consistent
and cleaner.

Thanks,
Adrian


[1] https://en.wikipedia.org/wiki/X32_ABI
[2] http://debian-x32.org/
[2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build


On 2018-09-05 01:27, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.02/


Looks good to me.

/Magnus



Fixed the comment in SourceRevision.gmk.

Added an SCM identifier in the string so a typical .src-rev file now 
looks like this:


.:hg:3f189f451ff1+

or like this:

.:git:2e1f2c6d44e5+

/Erik


On 2018-09-04 15:00, Erik Joelsson wrote:
There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project 
Skara aims to investigate Git as well. To better support this, the 
build needs to be able to support Git as an alternative to Mercurial 
when creating the identification hash in the release file. It would 
also be convenient with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

Re: Linux + Clang + execstack

On 2018-09-05 04:06, Martin Buchholz wrote:

Here's Arthur's patch:

8205457: gcc and clang should use the same ld flags
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ 

https://bugs.openjdk.java.net/browse/JDK-8205457

This applies -Wl,-z,noexecstack uniformly to all linker invocations 
where applicable.

TODO:
All ld flags on Linux should be treated equally by gcc and clang

Just FYI: I'm on a long-term mission to clean up the flag handling in 
the entire build. There's a lot of weird stuff going on with the flags, 
like "why do we do like this on this platform, and like that on that 
platform? shouldn't they be the same?". And most of the time, yes, they 
probably should be the same. But at other times, there's a reason they 
are different and the difference is a deliberate bug fix. It takes time, 
effort and a lot of repository archeology to figure that out.

/Magnus

The test TestCheckJDK and supporting infrastructure should stop 
advertising itself as only dealing with libraries.

Maybe add GNU-stack annotations to all the Linux .s files as well?

On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz > wrote:

I think we can all agree that passing flags to the linker to
ensure non-executable stack is the right thing to do.  But there's
a question whether *also* adding something to our assembly
language source files will be worth doing.  Neither mechanism is
sure to work.  For the linker flag, we need to be aware of and
test for the presence of the linker flag, but we might be using
some other linker... Similarly, we might end up using some other
assembler, or we might need to mark the assembly source file in a
different way than "GNU-stack".

On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie
mailto:magnus.ihse.bur...@oracle.com>> wrote:

On 2018-08-21 02:03, David Holmes wrote:

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:

On Mon, Aug 20, 2018 at 4:18 PM David Holmes
mailto:david.hol...@oracle.com>
>> wrote:

    Hi Arthur,

    cc'ing build-dev as this is currently a build issue.

    On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on
Linux with clang. One
    thing that
 > happens is that the resulting libjvm.so is
stack executable. When
    running
 > hotspot we get warnings about the stack being
executable.
 >
 > Compiling an assembly file into the final .so
results in the
    stack being
 > executable. In this case the file is
linux_x86_64.s. This doesn't
    happen
 > with gcc because "-Wl,-z,noexecstack" is passed
as a hotspot
    linker flag
 > with gcc in flags-ldflags.m4. When using clang
that linker flag isn't
 > passed.
 >
 > Doing something like the solution in
 >
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks

 > fixes the problem without the use of linker flags.

    You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for
the assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif

    I think I prefer to see this handled explicitly in
the build as is
    currently done. Can we just adjust
./make/autoconf/flags-ldflags.m4 to
    pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the
right thing to do is to fix things at the source level
and remove extra unnecessary linker flags.

Personally I see this as source code pollution. The
concept of executable stacks has nothing to do with what
is being expressed by the source code, or the language
used for it.

Just my 2c. I'll defer to build folk ... though they are
still on vacation at the moment.

I agree with David. The executable stack is a build option.
Even if you change the source code so the

Re: Linux + Clang + execstack

On 2018-09-05 01:01, Martin Buchholz wrote:
I think we can all agree that passing flags to the linker to ensure 
non-executable stack is the right thing to do. But there's a question 
whether *also* adding something to our assembly language source files 
will be worth doing.  Neither mechanism is sure to work.  For the 
linker flag, we need to be aware of and test for the presence of the 
linker flag, but we might be using some other linker...

For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified
TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"

We make sure we have an ld that supports the basic flags we assume.

We can add a similar check for the clang toolchain, if you want.

Mixing and matching compilers and linkers willy-nilly is not a supported 
build option, and there's no point in adding extra guards against such a 
thing. If you do that, and it turns out your build ended up broken, 
tough sh*t.

So I'll insist that adding the linker flag is sufficient to make sure 
this works, and that modifying the .s files are not necessary and will 
provide no benefit.

/Magnus

Similarly, we might end up using some other assembler, or we might 
need to mark the assembly source file in a different way than "GNU-stack".

On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie 
mailto:magnus.ihse.bur...@oracle.com>> 
wrote:

On 2018-08-21 02:03, David Holmes wrote:

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:

On Mon, Aug 20, 2018 at 4:18 PM David Holmes
mailto:david.hol...@oracle.com>
>> wrote:

    Hi Arthur,

    cc'ing build-dev as this is currently a build issue.

    On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on Linux
with clang. One
    thing that
 > happens is that the resulting libjvm.so is stack
executable. When
    running
 > hotspot we get warnings about the stack being
executable.
 >
 > Compiling an assembly file into the final .so
results in the
    stack being
 > executable. In this case the file is
linux_x86_64.s. This doesn't
    happen
 > with gcc because "-Wl,-z,noexecstack" is passed as
a hotspot
    linker flag
 > with gcc in flags-ldflags.m4. When using clang that
linker flag isn't
 > passed.
 >
 > Doing something like the solution in
 >
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks

 > fixes the problem without the use of linker flags.

    You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for the
assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif

    I think I prefer to see this handled explicitly in the
build as is
    currently done. Can we just adjust
./make/autoconf/flags-ldflags.m4 to
    pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the right
thing to do is to fix things at the source level and
remove extra unnecessary linker flags.

Personally I see this as source code pollution. The concept of
executable stacks has nothing to do with what is being
expressed by the source code, or the language used for it.

Just my 2c. I'll defer to build folk ... though they are still
on vacation at the moment.

I agree with David. The executable stack is a build option. Even
if you change the source code so the compiler/assember does the
right thing, we would still want to keep the compiler option.
(Otherwise one day you'll end up with executable stacks due to
someone adding a new asm file and forgetting the "magic incantation".)

And, since we will keep the compiler option, there seems little
point in also adding this stuff to the asm files.

To address your concerns on clang: we should reasonably be giving
the same options to clang. There is no good reason, except for
oversight, that this is not done already. (Cleaning up and
unifying the compiler flags is an ongoing, but slowly moving,
process.) So the correct fix is to update flags-ldflags.m4.

/Magnus

I removed "-Wl,-z,noexecstack" from the flags after adding
the

Re: Compiling OpenJDK8 with LLVM for mips64el


On 2018-09-05 06:03, Leslie Zhai wrote:

Hi all,

Thanks for Aleksandar Beserminji great job:

https://reviews.llvm.org/D50437

It is not easy to reproduce the LLVMBUG-38221[1] by building 
OpenJDK8,  it needs some workaround


https://raw.githubusercontent.com/xiangzhai/jdk8u-dev/master/Workaround-compile-with-llvm.patch 



Hi Leslie,

Great to see that this combination works as well with just so little 
tweaking!


However, since the mips64 port is not in upstream (in fact, it's 
currently not even an OpenJDK project), I think this patch better goes 
to the mips-port list.


/Magnus



LLVM toolchain[2] is just able to compile OpenJDK8 for mips64el now:

http://hg.loongnix.org/

1. https://bugs.llvm.org/show_bug.cgi?id=38221#c10

2. $ clang -v
Loongson clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 
56fc90882612ab774dae937ca8d997c59364f7f8) 
(g...@github.com:llvm-mirror/llvm.git 
3419b04cf0c0a57577865f0d17fefb205deed048) (based on LLVM 8.0.0svn)

Target: mips64el-redhat-linux
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: 
/usr/bin/../lib/gcc/mips64el-redhat-linux/4.9.3
Found candidate GCC installation: 
/usr/lib/gcc/mips64el-redhat-linux/4.9.3
Selected GCC installation: 
/usr/bin/../lib/gcc/mips64el-redhat-linux/4.9.3

Candidate multilib: .;
Selected multilib: .;

Re: Compiling OpenJDK8 with LLVM for mips64el