Re: RFR: 8275512: Upgrade required version of jtreg to 6.1 [v2]

2021-10-20 Thread Leslie Zhai 
On Tue, 19 Oct 2021 17:24:17 GMT, Weijun Wang  wrote:

>> As a follow up of JEP 411, we will soon disallow security manager by 
>> default. jtreg 6.1 does not set its own security manager if JDK version is 
>> >= 18.
>
> Weijun Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   upgrade the version in GHA config
>   
>   only in patch2:
>   unchanged:

Hi @wangweij 

But how to be suitable for jtreg version 6-dev+0?


Running tests using JTREG control variable 
'VM_OPTIONS=-XX:+UseZGC;TIMEOUT_FACTOR=20;VERBOSE=summary'
Test selection 'tier1', will run:
* jtreg:test/hotspot/jtreg:tier1
* jtreg:test/jdk:tier1
* jtreg:test/langtools:tier1
* jtreg:test/jaxp:tier1
* jtreg:test/lib-test:tier1

Running test 'jtreg:test/hotspot/jtreg:tier1'
Error: The testsuite at /var/lib/jenkins/repos/openjdk/jdk/test/hotspot/jtreg 
requires jtreg version 6.1 b1 or higher and this is jtreg version 6-dev+0.


Thanks,
Leslie Zhai

-

PR: https://git.openjdk.java.net/jdk/pull/6012

Re: RFC: Update test documentation by deleting "cd test && make"

2019-03-24 Thread Leslie Zhai 

Hi David,

Webrev: http://cr.openjdk.java.net/~lzhai/8221357/webrev.01/

A patch by Jing Tian 
He also fixed two existing grammar issues.

Please review it.

Thanks,
Leslie Zhai

Re: RFC: Update test documentation by deleting "cd test && make"

2019-03-24 Thread Leslie Zhai 

Hi David,

Thanks for your kind response!

> Webrev: http://cr.openjdk.java.net/~lzhai/8221357/webrev.00/

A patch by Jing Tian 
I just help him to host his patch on my cr.openjdk.java.net.

> That seems fine to me. Could I ask you to also fix two existing 
grammar issues...


Thanks for your review!  @Jing Tian  please fix the issue.

Thanks,
Leslie Zhai

Re: RFC: Update test documentation by deleting "cd test && make"

2019-03-22 Thread Leslie Zhai 

Hi,

JBS: https://bugs.openjdk.java.net/browse/JDK-8221357

Webrev: http://cr.openjdk.java.net/~lzhai/8221357/webrev.00/

Cheers,

Leslie Zhai


在 2019年03月22日 15:10, jingtian 写道:

Hi,

`cd test && make` is not supported any more.

It might be better to update  jdk/doc .

Cheers,
JingTian

Re: Fail to make images when enable ASan for OpenJDK X86 with LLVM toolchain

2019-03-21 Thread Leslie Zhai 

Hi Erik,


在 2019年03月20日 00:51, Erik Joelsson 写道:

Hello Leslie,

The failure you see is happening when the newly built exploded image 
is used for the first time. I'm not familiar with ASAN, but it seems 
that the JDK you create does not quite work. There are some ways 
around this.


Indeed.  Stack alignment issue:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux_x86.cpp:818
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/home/xiangzhai/project/jdk/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:818), 
pid=21908, tid=21909
#  assert(((intptr_t)os::current_stack_pointer() & 
(StackAlignmentInBytes-1)) == 0) failed: incorrect stack alignment

#
# JRE version:  (13.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 
13-internal+0-adhoc.xiangzhai.jdk, mixed mode, tiered, compressed oops, 
g1 gc, linux-amd64)

# Problematic frame:
# V  [libjvm.so+0x120e3a5]  os::verify_stack_alignment()+0x15
- 8<  8<  8<  8<  8<  8< ---

Martin filed the bug[1].  It also effect jdk12-mips64el.  But jdk8u is 
able to work compiled with clang-8[2].


[1] https://bugs.openjdk.java.net/browse/JDK-8186780
[2] 
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007890.html 






If you are unfamiliar with the exploded image, it's something we 
create while building everything (classes, libraries etc) that can run 
directly, but will not be as performant as the real jlinked image that 
the "images" target creates. Normally you build this with "make 
exploded-image" or "make jdk", but this includes the optimization step 
that is failing for you. To build just the exploded image and skip the 
optimization step, you can run "make exploded-image-base". In the 
build output you find the exploded image in 
build/linux-x86_64-server-fastdebug/jdk.  After your failure, you 
should be able to investigate this image by running things directly in 
it. From there you should be able to see if there is a problem with 
the binaries you built.


Another thing that could help you (perhaps not right now since it 
fails too early, but in general when you add special instrumentation 
to the build) is to first build a normal JDK. Then when you configure 
your special build, add --with-build-jdk=/path/to/normal/image. The 
"build-jdk" must exactly match the sources of the special build you 
are building and will be used for running all the jmod/jlink etc steps 
in the build instead of your special JDK build.


/Erik

On 2019-03-19 08:33, Leslie Zhai wrote:

Hi,

I want to run dynamic analysis test with the help of Address 
Sanitizer.  And I read the blog 'Running Java with 
AddressSanitizer'[1]  wrote by Artem who also added support for 
ASan[2].  Thanks for his great job!


But I failed to make images for X86:

Compiling 4 files for BUILD_JIGSAW_TOOLS
ERROR: Invalid value for bool option: '0"'
ERROR: Flag parsing failed.
ExplodedImageOptimize.gmk:39: recipe for target 
'/home/xiangzhai/project/jdk/build/linux-x86_64-server-fastdebug/jdk/_optimize_image_exec.marker' 
failed
gmake[3]: *** 
[/home/xiangzhai/project/jdk/build/linux-x86_64-server-fastdebug/jdk/_optimize_image_exec.marker] 
Error 1

make/Main.gmk:372: recipe for target 'exploded-image-optimize' failed
gmake[2]: *** [exploded-image-optimize] Error 1

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

Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
ERROR: Invalid value for bool option: '0"'
ERROR: Flag parsing failed.

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

jdk__optimize_image_exec.cmdline[3], 
jdk__optimize_image_exec.log[4],  and dynamic analysis report[5] by 
running the cmdline.


using configure arguments '--with-toolchain-type=clang 
--disable-warnings-as-errors --enable-asan 
--with-boot-jdk=/home/xiangzhai/jdk-11.0.2 --with-debug-level=fastdebug'


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

And I also make images with extra CFLAGS, CXXFLAGS and LDFLAGS to 
enable TSan for mips64el with LLVM toolchain especially integrated 
assembler:


sh configure --with-toolchain-type=clang \
  --disable-warnings-as-errors \
--with-boot-jdk=/home/loongson/zhaixiang/jdk-mips-f21-build-server-release-072 
\

  --with-debug-level=fastdebug \
  --with-extra-cflags="-fintegrated-as -fsanitize=thread" \
  --with-extra-cxxflags="-fintegrated-as -fsanitize=thread" \
  --with-extra-ldflags="-fsanitize=thread"

Although successfully built libjvm.so,  it means make hotspot works,  
failed to bootstrap near the end of make images.


So workaround might be make images at fir

Re: Fail to make images when enable ASan for OpenJDK X86 with LLVM toolchain

2019-03-19 Thread Leslie Zhai 

Hi Erik,

Thanks for your kind response!


在 2019年03月20日 00:51, Erik Joelsson 写道:

Hello Leslie,

The failure you see is happening when the newly built exploded image 
is used for the first time. I'm not familiar with ASAN, but it seems 
that the JDK you create does not quite work. There are some ways 
around this.


If you are unfamiliar with the exploded image, it's something we 
create while building everything (classes, libraries etc) that can run 
directly, but will not be as performant as the real jlinked image that 
the "images" target creates. Normally you build this with "make 
exploded-image" or "make jdk", but this includes the optimization step 
that is failing for you. To build just the exploded image and skip the 
optimization step, you can run "make exploded-image-base". In the 
build output you find the exploded image in 
build/linux-x86_64-server-fastdebug/jdk.  After your failure, you 
should be able to investigate this image by running things directly in 
it. From there you should be able to see if there is a problem with 
the binaries you built.


I will try.
Thanks,
Leslie Zhai




Another thing that could help you (perhaps not right now since it 
fails too early, but in general when you add special instrumentation 
to the build) is to first build a normal JDK. Then when you configure 
your special build, add --with-build-jdk=/path/to/normal/image. The 
"build-jdk" must exactly match the sources of the special build you 
are building and will be used for running all the jmod/jlink etc steps 
in the build instead of your special JDK build.


/Erik

On 2019-03-19 08:33, Leslie Zhai wrote:

Hi,

I want to run dynamic analysis test with the help of Address 
Sanitizer.  And I read the blog 'Running Java with 
AddressSanitizer'[1]  wrote by Artem who also added support for 
ASan[2].  Thanks for his great job!


But I failed to make images for X86:

Compiling 4 files for BUILD_JIGSAW_TOOLS
ERROR: Invalid value for bool option: '0"'
ERROR: Flag parsing failed.
ExplodedImageOptimize.gmk:39: recipe for target 
'/home/xiangzhai/project/jdk/build/linux-x86_64-server-fastdebug/jdk/_optimize_image_exec.marker' 
failed
gmake[3]: *** 
[/home/xiangzhai/project/jdk/build/linux-x86_64-server-fastdebug/jdk/_optimize_image_exec.marker] 
Error 1

make/Main.gmk:372: recipe for target 'exploded-image-optimize' failed
gmake[2]: *** [exploded-image-optimize] Error 1

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

Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
ERROR: Invalid value for bool option: '0"'
ERROR: Flag parsing failed.

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

jdk__optimize_image_exec.cmdline[3], 
jdk__optimize_image_exec.log[4],  and dynamic analysis report[5] by 
running the cmdline.


using configure arguments '--with-toolchain-type=clang 
--disable-warnings-as-errors --enable-asan 
--with-boot-jdk=/home/xiangzhai/jdk-11.0.2 --with-debug-level=fastdebug'


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

And I also make images with extra CFLAGS, CXXFLAGS and LDFLAGS to 
enable TSan for mips64el with LLVM toolchain especially integrated 
assembler:


sh configure --with-toolchain-type=clang \
  --disable-warnings-as-errors \
--with-boot-jdk=/home/loongson/zhaixiang/jdk-mips-f21-build-server-release-072 
\

  --with-debug-level=fastdebug \
  --with-extra-cflags="-fintegrated-as -fsanitize=thread" \
  --with-extra-cxxflags="-fintegrated-as -fsanitize=thread" \
  --with-extra-ldflags="-fsanitize=thread"

Although successfully built libjvm.so,  it means make hotspot works,  
failed to bootstrap near the end of make images.


So workaround might be make images at first without ASan nor TSan, 
then make hotspot with ASan or TSan?


Thanks,

Leslie Zhai

[1] 
https://blog.gypsyengineer.com/en/security/running-java-with-addresssanitizer.html


[2] https://bugs.openjdk.java.net/browse/JDK-8189800

[3] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/jdk__optimize_image_exec.cmdline


[4] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/jdk__optimize_image_exec.log


[5] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/make-enable-asan.log

Fail to make images when enable ASan for OpenJDK X86 with LLVM toolchain

2019-03-19 Thread Leslie Zhai 

Hi,

I want to run dynamic analysis test with the help of Address Sanitizer.  
And I read the blog 'Running Java with AddressSanitizer'[1]  wrote by 
Artem who also added support for ASan[2].  Thanks for his great job!


But I failed to make images for X86:

Compiling 4 files for BUILD_JIGSAW_TOOLS
ERROR: Invalid value for bool option: '0"'
ERROR: Flag parsing failed.
ExplodedImageOptimize.gmk:39: recipe for target 
'/home/xiangzhai/project/jdk/build/linux-x86_64-server-fastdebug/jdk/_optimize_image_exec.marker' 
failed
gmake[3]: *** 
[/home/xiangzhai/project/jdk/build/linux-x86_64-server-fastdebug/jdk/_optimize_image_exec.marker] 
Error 1

make/Main.gmk:372: recipe for target 'exploded-image-optimize' failed
gmake[2]: *** [exploded-image-optimize] Error 1

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

Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
ERROR: Invalid value for bool option: '0"'
ERROR: Flag parsing failed.

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

jdk__optimize_image_exec.cmdline[3], jdk__optimize_image_exec.log[4],  
and dynamic analysis report[5] by running the cmdline.


using configure arguments '--with-toolchain-type=clang 
--disable-warnings-as-errors --enable-asan 
--with-boot-jdk=/home/xiangzhai/jdk-11.0.2 --with-debug-level=fastdebug'


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

And I also make images with extra CFLAGS, CXXFLAGS and LDFLAGS to enable 
TSan for mips64el with LLVM toolchain especially integrated assembler:


sh configure --with-toolchain-type=clang \
  --disable-warnings-as-errors \
--with-boot-jdk=/home/loongson/zhaixiang/jdk-mips-f21-build-server-release-072 
\

  --with-debug-level=fastdebug \
  --with-extra-cflags="-fintegrated-as -fsanitize=thread" \
  --with-extra-cxxflags="-fintegrated-as -fsanitize=thread" \
  --with-extra-ldflags="-fsanitize=thread"

Although successfully built libjvm.so,  it means make hotspot works,  
failed to bootstrap near the end of make images.


So workaround might be make images at first without ASan nor TSan, then 
make hotspot with ASan or TSan?


Thanks,

Leslie Zhai

[1] 
https://blog.gypsyengineer.com/en/security/running-java-with-addresssanitizer.html


[2] https://bugs.openjdk.java.net/browse/JDK-8189800

[3] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/jdk__optimize_image_exec.cmdline


[4] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/jdk__optimize_image_exec.log


[5] 
https://raw.githubusercontent.com/xiangzhai/jdk-dev/master/make-enable-asan.log

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

2019-01-24 Thread Leslie Zhai 

Hi Erik,

Thanks for your kind response!

在 2019/1/25 上午1:19, Erik Joelsson 写道:

Hello,

I agree with the conclusion here, there is certainly a bug in the 
build logic. When creating the "Build JDK" during a cross compilation 
build, we are, as Magnus said, cutting a few corners for efficiency. 
One of those corners is assuming all the java classes are the same and 
can simply be reused. It has been shown here that that assumption is 
not always correct.


I think the most reasonable solution is to assume all of java.base 
needs to be built specifically for the "Build JDK". I think this can 
be reasonably easy to implement (compared to the existing Build JDK 
logic, which is arguably rather hairy).


Magnus' suggested workaround should work fine for now however.


Failed to make images 
https://mail.openjdk.java.net/pipermail/build-dev/2019-January/024765.html


But please point out my fault, thanks a lot!





Filed https://bugs.openjdk.java.net/browse/JDK-8217739


Thanks for your bug report!

Regards,

Leslie Zhai





/Erik

On 2019-01-24 05:30, Magnus Ihse Bursie wrote:

On 2019-01-24 13:22, Leslie Zhai wrote:

Hi Magnus,

Thanks for your kind response!

在 2019/1/24 下午8:05, Magnus Ihse Bursie 写道:



On 2019-01-24 05:45, David Holmes wrote:

On 24/01/2019 1:51 pm, Ao Qi wrote:

Hi David,

On Thu, Jan 24, 2019 at 10:47 AM David Holmes 
 wrote:


Hi Leslie,

I'm not Erik :) however 

On 24/01/2019 12:28 pm, Leslie Zhai wrote:

Hi Erik,

Because the flags' macro of MIPS is different from other 
targets[1], it

will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, 
for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is 
different

from other targets.  Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].


It's been quite a while since we built for a platform where the 
flags
had different values, but it is supposed to work. I suspect that 
the way
we build now with the module system may not be quite correct in 
this
regard - but that is just supposition on my part. Because 
compile-time
constants are stored directly into class files that use them, we 
have to
generate UnixConstants.java before compiling any class that 
needs to use
it, then we must compile all classes that do use it. Those 
classes must

only be executed in conjunction with a tool executing on the target
platform (javac, jmod etc). My suspicion is that we may be 
executing a

tool on the build platform using the newly compiled classes for the
target platform - and that would be wrong.



Yes. Some variables in UnixConstants.java is defined according to 
the

target (fcntl.h of mips in this case), but would be executed on host
(x86 in this case) during "make images". These variables of ppc64le,
aarch64 and s390x are the same as x86, but the ones of mips are not.
However, mips is not an official supported target and I did not find
other targets have similar issue, I am not sure if this is a bug 
or if

this is the right mailing list :)


This is the right mailing list to discuss. :)

So I went back to find when this happened in the past and I 
mis-remembered how we solved it. We previously had a problem with 
the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 
platforms defined a different value for the O_NOFOLLOW and 
O_DIRECT flags. The solution then was to commit a platform 
specific version of UnixConstants.java and change the build system 
to only use the template file if there was not a pre-existing 
.java file. But that platform and the SE Embedded support was all 
removed. (SocketOptions.java had a similar problem.) Further that 
build logic is completely different to what we had back then (JDK 
6/7).


This is definitely a bug in our build logic IMHO as we 
specifically use the build platform c-pre-processor to process the 
template file based on the target header files, but then use the 
resulting class when running tools on the build platform. 
I agree with David. This is a bug in the build system; arguably 
even a regression.


This was not something that happened in 6/7 or even 8 and I think 
the module system tools are where the issue now lies.


I think Erik and/or Magnus will have to give advice on how this 
may be properly fixed. I can't see any simple solution.

Unfortunately, I also agree that there is no simple solution. :-(

The proper way to handle this is to generate two versions of 
UnixConstants and friends, one for the build platform, and one for 
the target platform. But as far as I know, there is no simple way 
to handle such complications in our current structure. Erik knows 
more about this, he was the one who designed the current solution 
for handling cross-compilation in the modularized world.


However, I can at least help you with a relatively simple 
workaround. First some background: When we cross-compile, we need 
not only a Boot JDK (of version cur

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

2019-01-24 Thread Leslie Zhai 

Hi Magnus,

Failed to make images:

$ make images CONF=mips
Building target 'images' in configuration 
'linux-mips64el-normal-server-fastdebug'
GenerateLinkOptData.gmk:61: recipe for target 
'/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' 
failed
make[3]: *** 
[/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist] 
Error 1
make[3]: *** Deleting file 
'/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist'

make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed
make[2]: *** [generate-link-opt-data] Error 2

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


=== Make failed targets repeated here ===
GenerateLinkOptData.gmk:61: recipe for target 
'/home/loongson/zhaixiang/jdk12-mips/build/linux-mips64el-normal-server-fastdebug/support/link_opt/classlist' 
failed

make/Main.gmk:441: recipe for target 'generate-link-opt-data' 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/loongson/zhaixiang/jdk12-mips/make/Init.gmk:300: recipe for target 
'main' failed

make[1]: *** [main] Error 2
/home/loongson/zhaixiang/jdk12-mips/make/Init.gmk:186: recipe for target 
'images' failed

make: *** [images] Error 2

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

My cross-compile configure option:

CC=mips64el-linux-gnuabi64-gcc CXX=mips64el-linux-gnuabi64-g++ sh 
./configure \

  --openjdk-target=mips64el-linux-gnuabi64 \
  --with-sysroot=/chroots/mips64el_stretch \
  --with-toolchain-path=/chroots/mips64el_stretch \
  --with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 \
  --disable-warnings-as-errors \
--with-freetype-lib=/chroots/mips64el_stretch/usr/lib/mips64el-linux-gnuabi64 
\

--with-freetype-include=/chroots/mips64el_stretch/usr/include/freetype2 \
  --with-debug-level=fastdebug \
  --with-build-jdk=build/buildjdk/jdk

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

buildjdk is OK:

$ sh configure --with-conf-name=buildjdk 
--with-boot-jdk=/home/loongson/aoqi/jdk-11.0.1 --disable-warnings-as-errors


$ make jdk CONF=buildjdk

Building target 'jdk' in configuration 'buildjdk'
Finished building target 'jdk' in configuration 'buildjdk'

Regards,

Leslie Zhai


在 2019/1/24 下午9:30, Magnus Ihse Bursie 写道:

On 2019-01-24 13:22, Leslie Zhai wrote:

Hi Magnus,

Thanks for your kind response!

在 2019/1/24 下午8:05, Magnus Ihse Bursie 写道:



On 2019-01-24 05:45, David Holmes wrote:

On 24/01/2019 1:51 pm, Ao Qi wrote:

Hi David,

On Thu, Jan 24, 2019 at 10:47 AM David Holmes 
 wrote:


Hi Leslie,

I'm not Erik :) however ....

On 24/01/2019 12:28 pm, Leslie Zhai wrote:

Hi Erik,

Because the flags' macro of MIPS is different from other 
targets[1], it

will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, 
for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is 
different

from other targets.  Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].


It's been quite a while since we built for a platform where the 
flags
had different values, but it is supposed to work. I suspect that 
the way

we build now with the module system may not be quite correct in this
regard - but that is just supposition on my part. Because 
compile-time
constants are stored directly into class files that use them, we 
have to
generate UnixConstants.java before compiling any class that needs 
to use
it, then we must compile all classes that do use it. Those 
classes must

only be executed in conjunction with a tool executing on the target
platform (javac, jmod etc). My suspicion is that we may be 
executing a

tool on the build platform using the newly compiled classes for the
target platform - and that would be wrong.



Yes. Some variables in UnixConstants.java is defined according to the
target (fcntl.h of mips in this case), but would be executed on host
(x86 in this case) during "make images". These variables of ppc64le,
aarch64 and s390x are the same as x86, but the ones of mips are not.
However, mips is not an official supported target and I did not find
other targets have similar issue, I am not sure if this is a bug 
or if

this is the right mailing list :)


This is the right mailing list to discuss. :)

So I went back to find when this happened in the past and I 
mis-remembered how we solved it. We previously had a problem with 
the Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 
platforms defined a different value for the O_NOFOLLOW and O_DIRECT 
flags. The solution then was to commit a platform specific version 
of UnixConstants.java and change t

Re: Fail to cross compiling jdk12 for mips64el-linux-gnu target

2019-01-24 Thread Leslie Zhai 

Hi Magnus,

Thanks for your kind response!

在 2019/1/24 下午8:05, Magnus Ihse Bursie 写道:



On 2019-01-24 05:45, David Holmes wrote:

On 24/01/2019 1:51 pm, Ao Qi wrote:

Hi David,

On Thu, Jan 24, 2019 at 10:47 AM David Holmes 
 wrote:


Hi Leslie,

I'm not Erik :) however 

On 24/01/2019 12:28 pm, Leslie Zhai wrote:

Hi Erik,

Because the flags' macro of MIPS is different from other 
targets[1], it

will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, 
for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is 
different

from other targets.  Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].


It's been quite a while since we built for a platform where the flags
had different values, but it is supposed to work. I suspect that 
the way

we build now with the module system may not be quite correct in this
regard - but that is just supposition on my part. Because compile-time
constants are stored directly into class files that use them, we 
have to
generate UnixConstants.java before compiling any class that needs 
to use
it, then we must compile all classes that do use it. Those classes 
must

only be executed in conjunction with a tool executing on the target
platform (javac, jmod etc). My suspicion is that we may be executing a
tool on the build platform using the newly compiled classes for the
target platform - and that would be wrong.



Yes. Some variables in UnixConstants.java is defined according to the
target (fcntl.h of mips in this case), but would be executed on host
(x86 in this case) during "make images". These variables of ppc64le,
aarch64 and s390x are the same as x86, but the ones of mips are not.
However, mips is not an official supported target and I did not find
other targets have similar issue, I am not sure if this is a bug or if
this is the right mailing list :)


This is the right mailing list to discuss. :)

So I went back to find when this happened in the past and I 
mis-remembered how we solved it. We previously had a problem with the 
Oracle Java SE Embedded PPC port where some Linux PPC-e500v2 
platforms defined a different value for the O_NOFOLLOW and O_DIRECT 
flags. The solution then was to commit a platform specific version of 
UnixConstants.java and change the build system to only use the 
template file if there was not a pre-existing .java file. But that 
platform and the SE Embedded support was all removed. 
(SocketOptions.java had a similar problem.) Further that build logic 
is completely different to what we had back then (JDK 6/7).


This is definitely a bug in our build logic IMHO as we specifically 
use the build platform c-pre-processor to process the template file 
based on the target header files, but then use the resulting class 
when running tools on the build platform. 
I agree with David. This is a bug in the build system; arguably even a 
regression.


This was not something that happened in 6/7 or even 8 and I think the 
module system tools are where the issue now lies.


I think Erik and/or Magnus will have to give advice on how this may 
be properly fixed. I can't see any simple solution.

Unfortunately, I also agree that there is no simple solution. :-(

The proper way to handle this is to generate two versions of 
UnixConstants and friends, one for the build platform, and one for the 
target platform. But as far as I know, there is no simple way to 
handle such complications in our current structure. Erik knows more 
about this, he was the one who designed the current solution for 
handling cross-compilation in the modularized world.


However, I can at least help you with a relatively simple workaround. 
First some background: When we cross-compile, we need not only a Boot 
JDK (of version current N-1) running on the build host platform, but 
we also need a Build JDK, based on the current source code, running on 
the build host. (This is for running jmod/jlink; it needs to be up to 
date). If we have no Build JDK present, we start by creating one 
ourselves. This is more or less the same output as running a normal, 
non-cross compiled, build on the build host. (But Erik found some ways 
to cut a few corners to save time.) Your problem is that the Build JDK 
is broken, since UnixConstants has the wrong values.

-
But you can supply your own working Build JDK to configure!

So, your workflow for cross-compiling to MIPS should be:
1) create a Build JDK, e.g. like this: "bash configure 
--with-conf-name=buildjdk && make jdk CONF=buildjdk"
2) create your cross-compilation JDK like this: "bash configure 
--openjdk-target=mipsel-unknown-linux-gnu 
--with-build-jdk=build/buildjdk/jdk"

... or something like that.
Then you can build your cross-compiled jdk with "make images CONF=mips".


I will try that, thanks a lot for your teaching!

Regards,

Leslie Zhai





In theory, you should rebuild your bui

Fail to cross compiling jdk12 for mips64el-linux-gnu target

2019-01-23 Thread Leslie Zhai 

Hi Erik,

Because the flags' macro of MIPS is different from other targets[1], it 
will effect the `UnixConstants` of 
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for 
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different 
from other targets.  Then failed[2] to cross compiling jdk12 for 
mips64el-linux-gnu target by following the document[3].


Workaround 1:

Only make hotspot, then scp 
build/linux-mips64el-normal-server-fastdebug/jdk/lib/server/libjvm.so to 
mips64el target machine, java version is able to work[4], but it needs 
to make images on mips64el target machine at first.


Workaround 2:

Just change[5] the flags' macro of MIPS to keep same with other 
targets.  Even if succeed to cross compiling, and java version is able 
to work on target machine, but jmod[6], javac, etc. failed to work.  
Because buildjdk/jdk/bin/jmod is x86-64, but images/jdk/bin/jmod is 
mips64el target, the flags' macro is still different in X86 host and 
MIPS target machine.


Please give me some advice about how to fix the root cause, thanks a lot!

Regards,

Leslie Zhai


1.

$ diff -Naur sysdeps/unix/sysv/linux/x86/bits/fcntl.h 
sysdeps/unix/sysv/linux/mips/bits/fcntl.h
--- sysdeps/unix/sysv/linux/x86/bits/fcntl.h    2019-01-23 
11:46:18.712301739 +0800
+++ sysdeps/unix/sysv/linux/mips/bits/fcntl.h    2019-01-23 
11:46:18.540304458 +0800

@@ -1,5 +1,5 @@
-/* O_*, F_*, FD_* bit values for Linux/x86.
-   Copyright (C) 2001-2017 Free Software Foundation, Inc.
+/* O_*, F_*, FD_* bit values for Linux.
+   Copyright (C) 1995-2017 Free Software Foundation, Inc.
    This file is part of the GNU C Library.

    The GNU C Library is free software; you can redistribute it and/or
@@ -13,24 +13,56 @@
    Lesser General Public License for more details.

    You should have received a copy of the GNU Lesser General Public
-   License along with the GNU C Library; if not, see
+   License along with the GNU C Library.  If not, see
    <http://www.gnu.org/licenses/>.  */

-#ifndef _FCNTL_H
+#ifndef    _FCNTL_H
 # error "Never use  directly; include  instead."
 #endif

-#ifdef __x86_64__
-# define __O_LARGEFILE    0
+#include 
+
+#define O_APPEND     0x0008
+#define O_SYNC         0x4010
+#define O_NONBLOCK     0x0080
+#define O_CREAT         0x0100    /* not fcntl */
+#define O_TRUNC         0x0200    /* not fcntl */
+#define O_EXCL         0x0400    /* not fcntl */
+#define O_NOCTTY     0x0800    /* not fcntl */
+#define O_ASYNC         0x1000
+
+#define __O_DIRECT     0x8000    /* Direct disk access hint.  */
+#define __O_DSYNC     0x0010    /* Synchronize data.  */
+
+#if _MIPS_SIM == _ABI64
+/* Not necessary, files are always with 64bit off_t.  */
+# define __O_LARGEFILE  0
+#else
+# define __O_LARGEFILE    0x2000    /* Allow large file opens. */
 #endif

-#ifdef __x86_64__
-/* Not necessary, we always have 64-bit offsets.  */
-# define F_GETLK64    5    /* Get record locking info.  */
-# define F_SETLK64    6    /* Set record locking info (non-blocking).  */
-# define F_SETLKW64    7    /* Set record locking info (blocking).    */
+#ifndef __USE_FILE_OFFSET64
+# define F_GETLK    14    /* Get record locking info.  */
+# define F_SETLK    6    /* Set record locking info (non-blocking).  */
+# define F_SETLKW    7    /* Set record locking info (blocking).    */
+#else
+# define F_GETLK    F_GETLK64  /* Get record locking info.    */
+# define F_SETLK    F_SETLK64  /* Set record locking info (non-blocking).*/
+# define F_SETLKW    F_SETLKW64 /* Set record locking info (blocking).  */
 #endif

+#if _MIPS_SIM != _ABI64
+# define F_GETLK64    33    /* Get record locking info.  */
+# define F_SETLK64    34    /* Set record locking info (non-blocking).  */
+# define F_SETLKW64    35    /* Set record locking info (blocking).    */
+#else
+# define F_GETLK64    14    /* Get record locking info.    */
+# define F_SETLK64    6    /* Set record locking info (non-blocking).*/
+# define F_SETLKW64    7    /* Set record locking info (blocking).  */
+#endif
+
+#define __F_SETOWN    24    /* Get owner (process receiving SIGIO).  */
+#define __F_GETOWN    23    /* Set owner (process receiving SIGIO).  */

 struct flock
   {
@@ -39,12 +71,23 @@
 #ifndef __USE_FILE_OFFSET64
 __off_t l_start;    /* Offset where the lock begins.  */
 __off_t l_len;    /* Size of the locked area; zero means until 
EOF.  */

+#if _MIPS_SIM != _ABI64
+    /* The 64-bit flock structure, used by the n64 ABI, and for 64-bit
+   fcntls in o32 and n32, never has this field.  */
+    long int l_sysid;
+#endif
 #else
 __off64_t l_start;    /* Offset where the lock begins.  */
 __off64_t l_len;    /* Size of the locked area; zero means until 
EOF.  */

 #endif
 __pid_t l_pid;    /* Process holding the lock.  */
+#if ! defined __USE_FILE_OFFSET64 && _MIPS_SIM != _ABI64
+    /* The 64-bit flock structure, used by the n64 ABI, and for 64-bit
+   flock in o32 and n32, never has this

Re: Failed to compile OpenJDK 12-dev by LLVM 8 for X86 with OpenJDK 10 boot jdk

2018-09-17 Thread Leslie Zhai 

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


在 2018年09月16日 13:21, Leslie Zhai 写道:

Hi,

I just want to verify JDK-8206183 and JDK-8205965 built with clang-8[1]

http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023172.html 



$ hg log | head
changeset:   51758:6c956c883137
tag: tip
user:    igerasim
date:    Sat Sep 15 13:53:43 2018 -0700
summary: 8210787: Object.wait(long, int) throws inappropriate 
IllegalArgumentException


$ ./configure --with-debug-level=fastdebug --with-toolchain-type=clang 
--with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors


Tools summary:
* Boot JDK:   openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime 
Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 
(build 10.0.2+13, mixed mode)  (at /home/xiangzhai/jdk-10.0.2)

* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 8.0.0 (at /opt/llvm-git/bin/clang)
* C++ Compiler:   Version 8.0.0 (at /opt/llvm-git/bin/clang++)

$ make images

...

Building target 'images' in configuration 
'linux-x86_64-normal-server-fastdebug'

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux_x86.cpp:833
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/home/xiangzhai/project/jdk/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:833), 
pid=3156, tid=3157
#  assert(((intptr_t)os::current_stack_pointer() & 
(StackAlignmentInBytes-1)) == 0) failed: incorrect stack alignment

#
# JRE version:  (12.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 
12-internal+0-adhoc.xiangzhai.jdk, mixed mode, tiered, compressed 
oops, serial gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be 
processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I" 
(or dumping to /home/xiangzhai/project/jdk/make/core.3156)

#
# An error report file with more information is saved as:
# /home/xiangzhai/project/jdk/make/hs_err_pid3156.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 3157
Dumping core ...

- 8<  8<  8<  8<  8<  8< ---
But clang-3.9[2] is OK!

Tools summary:
* Boot JDK:   openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime 
Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 
(build 10.0.2+13, mixed mode)  (at /home/xiangzhai/jdk-10.0.2)

* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 3.9.1 (at /usr/bin/clang)
* C++ Compiler:   Version 3.9.1 (at /usr/bin/clang++)

$ strings 
./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java | 
grep clang

clang version 3.9.1 (tags/RELEASE_391/final)

$ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java 
-version

openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (slowdebug build 
12-internal+0-adhoc.xiangzhai.jdk)
OpenJDK 64-Bit Server VM (slowdebug build 
12-internal+0-adhoc.xiangzhai.jdk, mixed mode)


[1] $ clang -v
LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 
7f223b8fbf26fa0e4d8f98847a53c4ba457720f0) 
(g...@github.com:llvm-mirror/llvm.git 
841e300fb15be4f9931d18d2f24f48cb59ef24a8) (based on LLVM 8.0.0svn)

Target: x86_64-redhat-linux
Thread model: posix
InstalledDir: /opt/llvm-git/bin
Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

[2] $ clang -v
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: 
/usr/bin/../lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: 
/usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1

Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64



--
Regards,
Leslie Zhai

Failed to compile OpenJDK 12-dev by LLVM 8 for X86 with OpenJDK 10 boot jdk

2018-09-15 Thread Leslie Zhai 

Hi,

I just want to verify JDK-8206183 and JDK-8205965 built with clang-8[1]

http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023172.html

$ hg log | head
changeset:   51758:6c956c883137
tag: tip
user:    igerasim
date:    Sat Sep 15 13:53:43 2018 -0700
summary: 8210787: Object.wait(long, int) throws inappropriate 
IllegalArgumentException


$ ./configure --with-debug-level=fastdebug --with-toolchain-type=clang 
--with-boot-jdk=/home/xiangzhai/jdk-10.0.2 --disable-warnings-as-errors


Tools summary:
* Boot JDK:   openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime 
Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 
10.0.2+13, mixed mode)  (at /home/xiangzhai/jdk-10.0.2)

* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 8.0.0 (at /opt/llvm-git/bin/clang)
* C++ Compiler:   Version 8.0.0 (at /opt/llvm-git/bin/clang++)

$ make images

...

Building target 'images' in configuration 
'linux-x86_64-normal-server-fastdebug'

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/os_linux_x86.cpp:833
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error 
(/home/xiangzhai/project/jdk/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:833), 
pid=3156, tid=3157
#  assert(((intptr_t)os::current_stack_pointer() & 
(StackAlignmentInBytes-1)) == 0) failed: incorrect stack alignment

#
# JRE version:  (12.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 
12-internal+0-adhoc.xiangzhai.jdk, mixed mode, tiered, compressed oops, 
serial gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be 
processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I" (or 
dumping to /home/xiangzhai/project/jdk/make/core.3156)

#
# An error report file with more information is saved as:
# /home/xiangzhai/project/jdk/make/hs_err_pid3156.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 3157
Dumping core ...

- 8<  8<  8<  8<  8<  8< ---
But clang-3.9[2] is OK!

Tools summary:
* Boot JDK:   openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime 
Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 
10.0.2+13, mixed mode)  (at /home/xiangzhai/jdk-10.0.2)

* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 3.9.1 (at /usr/bin/clang)
* C++ Compiler:   Version 3.9.1 (at /usr/bin/clang++)

$ strings 
./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java | grep 
clang

clang version 3.9.1 (tags/RELEASE_391/final)

$ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version
openjdk version "12-internal" 2019-03-19
OpenJDK Runtime Environment (slowdebug build 
12-internal+0-adhoc.xiangzhai.jdk)
OpenJDK 64-Bit Server VM (slowdebug build 
12-internal+0-adhoc.xiangzhai.jdk, mixed mode)


[1] $ clang -v
LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 
7f223b8fbf26fa0e4d8f98847a53c4ba457720f0) 
(g...@github.com:llvm-mirror/llvm.git 
841e300fb15be4f9931d18d2f24f48cb59ef24a8) (based on LLVM 8.0.0svn)

Target: x86_64-redhat-linux
Thread model: posix
InstalledDir: /opt/llvm-git/bin
Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

[2] $ clang -v
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: 
/usr/bin/../lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: 
/usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1

Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

--
Regards,
Leslie Zhai

Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86

2018-09-13 Thread Leslie Zhai 

Hi Zhengyu,

Thanks for your patch!  I will backport it to jdk8u and test it for X86 
and mips64el.


Thanks,

Leslie Zhai


在 2018年09月12日 20:58, Zhengyu Gu 写道:
Probably should also backport the followup RFE: 
https://bugs.openjdk.java.net/browse/JDK-8206183


Thanks,

-Zhengyu

On 09/11/2018 10:58 PM, David Holmes wrote:
Or to be a little less obscure, this is a known issue and you should 
look into backporting:


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

David

On 12/09/2018 5:03 AM, Martin Buchholz wrote:

https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m

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

2018-09-13 Thread Leslie Zhai 

Hi Andrew,

Thanks for your kind response!


在 2018年09月11日 01:19, Andrew Hughes 写道:

On Wed, 5 Sep 2018 at 10:52, Leslie Zhai  wrote:

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



Is this the OpenJDK 8 build? It's quite different to the OpenJDK 9+ build I was
referring to in my e-mail.

Yes, I am compiling OpenJDK 8 with LLVM for mips64el
http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023074.html



There are effectively three different OpenJDK build systems:

1. OpenJDK 6 & 7 - the old legacy make & Ant build throughtout
2. OpenJDK 8 - new configure & make build for most repositories, but invoking
the old legacy build for HotSpot
3. OpenJDK 9 - full  new configure & make build across the board

This leaves OpenJDK 8 as unique and quite confusing. It means when backporting
build changes from 9+, they essentially have to be duplicated to apply
to the HotSpot
part of the build as well.

I'm aware of the build warning due to -std in the backport to 8. It
was unavoidable
as the older build only uses CFLAGS, and primarily for C++ code. There is simply
no variable to add it to instead. CXXFLAGS is used there as a variable for some
preprocessor directives :

hotspot/make/linux/makefiles/rules.make:CC_COMPILE   = $(CC)
$(CXXFLAGS) $(CFLAGS)
hotspot/make/linux/makefiles/rules.make:CXX_COMPILE  = $(CXX)
$(CXXFLAGS) $(CFLAGS)

Trying to alter this at this stage in 8u's development is really too
dangerous, considering
the range of systems relying on being able to build 8u. I'm already a
little worried by the
number of build system changes coming into 8u. I would regard the
build system for
a legacy release as needing the same stability guarantees as the code itself.

Certainly removing EXTRA_CFLAGS is not appropriate as this code will
then be built
without flags passed in by configure and other additions made by
configure checks.
Sorry for my monkey patch, I will rebase the workaround compile with 
llvm patch.



Being able to build without that is one thing. Being able to ensure
there are no regressions
on all builds is quite another and we've already seen an issue where
flags for GCC >= 6
were

Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86

2018-09-11 Thread Leslie Zhai 

Hi,

Thanks for your kind response!


在 2018年09月12日 10:58, David Holmes 写道:
Or to be a little less obscure, this is a known issue and you should 
look into backporting:


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

Already known :)
http://mail.openjdk.java.net/pipermail/build-dev/2018-September/023181.html

But I want to find out which commit or review bring in the "issue" in 
the LLVM side:

http://lists.llvm.org/pipermail/llvm-dev/2018-September/125994.html





David

On 12/09/2018 5:03 AM, Martin Buchholz wrote:

https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m



--
Regards,
Leslie Zhai

Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86

2018-09-11 Thread Leslie Zhai 
16(%rip)
 movq$0, NativeCallStack::EMPTY_STACK+24(%rip)
 ret
 .cfi_endproc
.LFE74:
 .size   main, .-main
 .p2align 4,,15
 .type   _GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE, @function
_GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE:
.LFB76:
 .cfi_startproc
 movq$0, NativeCallStack::EMPTY_STACK(%rip)
 movq$0, NativeCallStack::EMPTY_STACK+8(%rip)
 movq$0, NativeCallStack::EMPTY_STACK+16(%rip)
 movq$0, NativeCallStack::EMPTY_STACK+24(%rip)
 ret
 .cfi_endproc
.LFE76:
 .size   _GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE, 
.-_GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE
 .section.ctors,"aw",@progbits
 .align 8
 .quad   _GLOBAL__sub_I__ZN15NativeCallStack11EMPTY_STACKE
 .globl  NativeCallStack::EMPTY_STACK
 .bss
 .align 32
 .type   NativeCallStack::EMPTY_STACK, @object
 .size   NativeCallStack::EMPTY_STACK, 32
NativeCallStack::EMPTY_STACK:
 .zero   32

Here you can see that gcc decided to not place EMPTY_STACK in .rodata,
but in .bss, which is read/write.  It adds the global constructor to
the .ctors section, so the dynamic linker is made responsible for
calling it.

Note that now the EMPTY_STACK object is unnecessarily initialized twice,
once by the global constructor, and once in main.

-Dimitry


On 11 Sep 2018, at 03:38, Leslie Zhai  wrote:

Hi Dimitry,

Thanks for your kind response!

Thanks for the commit message of Jung's patch,  I found that the bug had been 
fixed in OpenJDK 12 by Zhengyu https://bugs.openjdk.java.net/browse/JDK-8205965 
 But only backported to 11.  So Jung could backport it for OpenJDK 8, thanks a 
lot!

But I argue that the root cause might be in the compiler side, why clang-3.9.1, 
gcc-6.4.1 couldn't reproduce the bug?  And it might be work for clang-4.0 
https://bugs.openjdk.java.net/browse/JDK-8208494  I will test LLVM 5 to check 
out whether or not reproducible.


在 2018年09月11日 00:59, Dimitry Andric 写道:

Hi Leslie,

This is likely the same problem as was reported in 
https://bugs.freebsd.org/225054#c8, and fixed by the following patch:

https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp?view=markup=459368

Can you please try that out, and see if it fixes it for you too?

-Dimitry


On 10 Sep 2018, at 18:20, Leslie Zhai via llvm-dev  
wrote:

Hi all,

OpenJDK8 jdk8u-dev[1] is just able to work after compiled with LLVM 3.9.1 for 
X86:

$ ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java 
-version
openjdk version "1.8.0-internal-debug"
OpenJDK Runtime Environment (build 
1.8.0-internal-debug-xiangzhai_2018_09_09_21_08-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode)

$ strings 
./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java | grep 
clang
clang version 3.9.1 (tags/RELEASE_391/final)

But it failed to work after compiled with LLVM 8 for X86:

$ ./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java 
-version
Segmentation fault

$ gdb --ex run --args 
./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java 
-version
GNU gdb (GDB) Fedora 7.12.1-48.fc25
...
Starting program: 
/home/xiangzhai/project/jdk8u-llvm/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
 -version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
[ Legend: Modified register | Code | Heap | Stack | String ]
───[
 registers ]
$rax   : 0x0
$rbx   : 0x0
$rcx   : 0x77315eb0  →  0x76ae30a0  → 
 xor edx, edx
$rdx   : 0x0
$rsp   : 0x7fff9328  →  0x76a76822  → 
 mov edi, ebx
$rbp   : 0x7fff93c0  →  0x7fff94f0  → 0x7fff9510  →  
0x0002
$rsi   : 0x0
$rdi   : 0x77315e70  →  0x77315eb0  → 0x76ae30a0  → 
 xor edx, edx
$rip   : 0x76ae2f5b  →  mov 
QWORD PTR [rdi], rcx
$r8: 0x1
$r9: 0xf
$r10   : 0x64
$r11   : 0x0
$r12   : 0x7fffdc88  →  0x7fffe04c  → 
"/home/xiangzhai/project/jdk8u-llvm/build/linux-x86[...]"
$r13   : 0x7fffdca0  →  0x7fffe0bf  → "XDG_VTNR=1"
$r14   : 0x7fff9330  →  "NMT_LEVEL_10535"
$r15   : 0x6
$eflags: [carry parity adjust zero sign trap INTERRUPT direction overflow 
RESUME virtualx86 identification]
$ss: 0x002b  $ds: 0x  $cs: 0x0033  $es: 0x  $gs: 0x $fs: 0x
───[
 stack ]
0x7fff9328│+0x00: 0x76a76822  → 
 mov edi, ebx← $rsp
0x7fff9330│+0x08: "NMT_LEVEL_10535&qu

Re: [llvm-dev] OpenJDK8 failed to work after compiled by LLVM 8 for X86

2018-09-10 Thread Leslie Zhai 

Hi Dimitry,

Thanks for your kind response!

Thanks for the commit message of Jung's patch,  I found that the bug had 
been fixed in OpenJDK 12 by Zhengyu 
https://bugs.openjdk.java.net/browse/JDK-8205965  But only backported to 
11.  So Jung could backport it for OpenJDK 8, thanks a lot!


But I argue that the root cause might be in the compiler side, why 
clang-3.9.1, gcc-6.4.1 couldn't reproduce the bug?  And it might be work 
for clang-4.0 https://bugs.openjdk.java.net/browse/JDK-8208494  I will 
test LLVM 5 to check out whether or not reproducible.



在 2018年09月11日 00:59, Dimitry Andric 写道:

Hi Leslie,

This is likely the same problem as was reported in 
https://bugs.freebsd.org/225054#c8, and fixed by the following patch:

https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp?view=markup=459368

Can you please try that out, and see if it fixes it for you too?

-Dimitry


On 10 Sep 2018, at 18:20, Leslie Zhai via llvm-dev  
wrote:

Hi all,

OpenJDK8 jdk8u-dev[1] is just able to work after compiled with LLVM 3.9.1 for 
X86:

$ ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java 
-version
openjdk version "1.8.0-internal-debug"
OpenJDK Runtime Environment (build 
1.8.0-internal-debug-xiangzhai_2018_09_09_21_08-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode)

$ strings 
./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java | grep 
clang
clang version 3.9.1 (tags/RELEASE_391/final)

But it failed to work after compiled with LLVM 8 for X86:

$ ./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java 
-version
Segmentation fault

$ gdb --ex run --args 
./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java 
-version
GNU gdb (GDB) Fedora 7.12.1-48.fc25
...
Starting program: 
/home/xiangzhai/project/jdk8u-llvm/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
 -version
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
[ Legend: Modified register | Code | Heap | Stack | String ]
───[
 registers ]
$rax   : 0x0
$rbx   : 0x0
$rcx   : 0x77315eb0  →  0x76ae30a0  → 
 xor edx, edx
$rdx   : 0x0
$rsp   : 0x7fff9328  →  0x76a76822  → 
 mov edi, ebx
$rbp   : 0x7fff93c0  →  0x7fff94f0  → 0x7fff9510  →  
0x0002
$rsi   : 0x0
$rdi   : 0x77315e70  →  0x77315eb0  → 0x76ae30a0  → 
 xor edx, edx
$rip   : 0x76ae2f5b  →  mov 
QWORD PTR [rdi], rcx
$r8: 0x1
$r9: 0xf
$r10   : 0x64
$r11   : 0x0
$r12   : 0x7fffdc88  →  0x7fffe04c  → 
"/home/xiangzhai/project/jdk8u-llvm/build/linux-x86[...]"
$r13   : 0x7fffdca0  →  0x7fffe0bf  → "XDG_VTNR=1"
$r14   : 0x7fff9330  →  "NMT_LEVEL_10535"
$r15   : 0x6
$eflags: [carry parity adjust zero sign trap INTERRUPT direction overflow 
RESUME virtualx86 identification]
$ss: 0x002b  $ds: 0x  $cs: 0x0033  $es: 0x  $gs: 0x $fs: 0x
───[
 stack ]
0x7fff9328│+0x00: 0x76a76822  → 
 mov edi, ebx← $rsp
0x7fff9330│+0x08: "NMT_LEVEL_10535"  ← $r14
0x7fff9338│+0x10: 0x0035333530315f4c ("L_10535"?)
0x7fff9340│+0x18: 0x0001
0x7fff9348│+0x20: 0x00602190  → 0x75eb7000  →  
0x00010102464c457f
0x7fff9350│+0x28: 0x0004
0x7fff9358│+0x30: 0x00066474e551
0x7fff9360│+0x38: 0x
[
 code:i386:x86-64 ]
0x76ae2f4b  addeax, 
0x1f0f00
0x76ae2f50  movrcx, QWORD 
PTR [rip+0x842781]# 0x773256d8
0x76ae2f57  addrcx, 0x10
  → 0x76ae2f5b  movQWORD PTR 
[rdi], rcx
0x76ae2f5e  movDWORD PTR 
[rdi+0x28], 0x0
0x76ae2f65  addrdi, 0x8
0x76ae2f69  test   edx, edx
0x76ae2f6b  je 0x76ae2f7b 

0x76ae2f6d  moveax, esi
─[ 
source:/home/xiangzhai/project/jdk8u-llvm/hotspot/src/share/vm/utilities/nativeCallStack.cpp+33
 ]
  28  #include "utilities/nativeCallStack.hpp"
  29
  30  const NativeCallStack NativeCallStack::EMPTY_STACK(0, false);
  31
  32  NativeCallStack::NativeCallStack(int toSkip, bool fillStack) :
  →   33_hash_value(0) {
  34
  35  #if !PLATFORM_NATIVE_STACK_WALKING_SUPPORTED
  36fillStack = false;
  37  #endif
  38
───

OpenJDK8 failed to work after compiled by LLVM 8 for X86

2018-09-10 Thread Leslie Zhai 
f97d0, 
errstring=0x7fff97d8, mallocedp=0x7fff97cf, 
operate=0x77decae0 , args=0x7fff97e0)


0x76ae2f5b in NativeCallStack::NativeCallStack 
(this=0x77315e70 , toSkip=0x0, 
fillStack=0x0) at 
/home/xiangzhai/project/jdk8u-llvm/hotspot/src/share/vm/utilities/nativeCallStack.cpp:33

33    _hash_value(0) {
gef➤  c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
gef➤

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

I started to use and contribute clang static analyzer[2] just for 
finding the bugs for open source software from LLVM 3.x,  perhaps it is 
a bug of LLVM 8,  because jdk8u is just able to print out '-version' 
after compiled with llvm-3.9.1,  I will rebuild the LLVM 8 again,  then 
rebuild jdk8u for triple check.


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


2. 
https://github.com/llvm-mirror/clang/commit/a530e823ed2793ac149de7a984014e242a787682#diff-ff9160d4628cb9b6186559837c2c8668


3. The build option of LLVM 8 (bootstrap with LLVM 3.9.1):

cmake .. -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_C_COMPILER=clang \
    -DCMAKE_CXX_COMPILER=clang++ \
    -DCMAKE_C_FLAGS="-fPIC" \
    -DCMAKE_CXX_FLAGS="-std=c++11 -fPIC" \
    -DLLVM_BUILD_LLVM_DYLIB=ON \
    -DLLVM_LINK_LLVM_DYLIB=ON \
    -DLLVM_INSTALL_UTILS=ON \
    -DLLVM_ENABLE_RTTI=ON \
    -DLLVM_ENABLE_FFI=ON \
    -DLLVM_ENABLE_EH=ON \
    -DLLVM_BUILD_TESTS=ON \
    -DLLVM_BUILD_DOCS=OFF \
    -DLLVM_ENABLE_SPHINX=OFF \
    -DLLVM_ENABLE_DOXYGEN=OFF \
    -DLLDB_DISABLE_LIBEDIT=1 \
    -DSPHINX_WARNINGS_AS_ERRORS=OFF \
    -DFFI_INCLUDE_DIR=$(pkg-config --variable=includedir libffi) \
    -DFFI_LIBRARY_DIR:PATH="$(pkg-config --variable=libdir libffi)" \
    -DLLVM_BINUTILS_INCDIR=/usr/include \
    -DLLVM_LIBDIR_SUFFIX=64 \
    -DLIBCXX_ENABLE_ABI_LINKER_SCRIPT=ON \
    -DLIBUNWIND_ENABLE_SHARED=ON \
    -DLIBCXXABI_USE_LLVM_UNWINDER=ON \
    -DLLDB_TEST_C_COMPILER=clang \
    -DLLDB_TEST_CXX_COMPILER=clang++ \
    -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-redhat-linux" \
    -DCLANG_VENDOR="LLVM China"

4. $ clang -v
LLVM China clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 
81ef98628ebf5186d746c0986dcbf5073e842043) 
(g...@github.com:llvm-mirror/llvm.git 
e1aac9723d55497e74d83d216329f08d9842e494) (based on LLVM 8.0.0svn)

Target: x86_64-redhat-linux
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: 
/usr/bin/../lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: 
/usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1

Found candidate GCC installation: /usr/lib/gcc/i686-redhat-linux/6.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/6.4.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/6.4.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

--
Regards,
Leslie Zhai

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

2018-09-05 Thread Leslie Zhai 
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 <mailto:zhaixi...@loongson.cn>> 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 Leslie Zhai 

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

2018-09-05 Thread Leslie Zhai 

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: Compiling OpenJDK8 with LLVM for mips64el

2018-09-05 Thread Leslie Zhai 

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

Compiling OpenJDK8 with LLVM for mips64el

2018-09-04 Thread Leslie Zhai 

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

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