Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v4]
On Tue, 25 Jun 2024 11:20:38 GMT, Matthias Baesken wrote: >> Sometimes it would be helpful to have configure-support for adding >> additional ubsan check options. >> E.g. support new configure option >> '--with-additional-ubsan-checks=' . > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust UTIL_ARG_WITH Thanks for the reviews ! The langtools error in 'Pre-submit tests - linux-x64 / test - Test (tier1) ' seems to be unrelated. - PR Comment: https://git.openjdk.org/jdk/pull/19802#issuecomment-2191723714
Integrated: 8334618: ubsan: support setting additional ubsan check options
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote: > Sometimes it would be helpful to have configure-support for adding additional > ubsan check options. > E.g. support new configure option > '--with-additional-ubsan-checks=' . This pull request has now been integrated. Changeset: efb905e5 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/efb905e57ab7a5299952419fa9961316541056c2 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8334618: ubsan: support setting additional ubsan check options Reviewed-by: stuefe, lucy - PR: https://git.openjdk.org/jdk/pull/19802
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v3]
On Mon, 24 Jun 2024 08:46:10 GMT, Erik Joelsson wrote: > We could have both --with-ubsan-checks= and --with-additional-ubsan-checks if > you think it would be useful. What are the preferences of the others ? Yeah it might be useful indeed (Kim proposed a flag for replacing the checks in the other JBS issue). - PR Comment: https://git.openjdk.org/jdk/pull/19802#issuecomment-2188669278
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v4]
> Sometimes it would be helpful to have configure-support for adding additional > ubsan check options. > E.g. support new configure option > '--with-additional-ubsan-checks=' . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust UTIL_ARG_WITH - Changes: - all: https://git.openjdk.org/jdk/pull/19802/files - new: https://git.openjdk.org/jdk/pull/19802/files/ad51358a..0b7402e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19802=03 - incr: https://webrevs.openjdk.org/?repo=jdk=19802=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/19802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19802/head:pull/19802 PR: https://git.openjdk.org/jdk/pull/19802
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v3]
On Fri, 21 Jun 2024 23:07:57 GMT, Kim Barrett wrote: > [Just a drive-by comment, not a review and not planning to review.] As a > user, syntactically I think I'd prefer something like the > `with-ubsan[=parameters]` approach suggested in the the probably duplicate > issue https://bugs.openjdk.org/browse/JDK-8306710. But that's not a strongly > held opinion. And I have no idea what would be better for the implementation. Your idea is more flexible (you can not just add something but overwrite the existing settings). However you have to set more ubsan parameters on the other hand, so both approaches have pros and cons. - PR Comment: https://git.openjdk.org/jdk/pull/19802#issuecomment-2183951780
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v3]
On Sat, 22 Jun 2024 07:21:15 GMT, Thomas Stuefe wrote: > Stupid question, could I not just pass `--with-extra-cxxflags` or similar, > and have the same effect? Technically probably yes, but wouldn't that be cflags AND cxxflags ? Another positive point with this PR - the added settings show up on the command line together with the other ubsan flags. - PR Comment: https://git.openjdk.org/jdk/pull/19802#issuecomment-2183951312
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v3]
> Sometimes it would be helpful to have configure-support for adding additional > ubsan check options. > E.g. support new configure option > '--with-additional-ubsan-checks=' . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: more lines - Changes: - all: https://git.openjdk.org/jdk/pull/19802/files - new: https://git.openjdk.org/jdk/pull/19802/files/6246d85a..ad51358a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19802=02 - incr: https://webrevs.openjdk.org/?repo=jdk=19802=01-02 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19802/head:pull/19802 PR: https://git.openjdk.org/jdk/pull/19802
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v2]
On Thu, 20 Jun 2024 12:48:40 GMT, Matthias Baesken wrote: >> Sometimes it would be helpful to have configure-support for adding >> additional ubsan check options. >> E.g. support new configure option >> '--with-additional-ubsan-checks=' . > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > use UTIL_ARG_WITH I adjusted the lines a bit. - PR Comment: https://git.openjdk.org/jdk/pull/19802#issuecomment-2182263398
Re: RFR: 8334618: ubsan: support setting additional ubsan check options
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote: > Sometimes it would be helpful to have configure-support for adding additional > ubsan check options. > E.g. support new configure option > '--with-additional-ubsan-checks=' . Thanks for the advice, UTIL_ARG_WITH makes the change much smaller. - PR Comment: https://git.openjdk.org/jdk/pull/19802#issuecomment-2180581690
Re: RFR: 8334618: ubsan: support setting additional ubsan check options [v2]
> Sometimes it would be helpful to have configure-support for adding additional > ubsan check options. > E.g. support new configure option > '--with-additional-ubsan-checks=' . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: use UTIL_ARG_WITH - Changes: - all: https://git.openjdk.org/jdk/pull/19802/files - new: https://git.openjdk.org/jdk/pull/19802/files/7c8cba89..6246d85a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=19802=01 - incr: https://webrevs.openjdk.org/?repo=jdk=19802=00-01 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19802/head:pull/19802 PR: https://git.openjdk.org/jdk/pull/19802
RFR: 8334618: ubsan: support setting additional ubsan check options
Sometimes it would be helpful to have configure-support for adding additional ubsan check options. E.g. support new configure option '--with-additional-ubsan-checks=' . - Commit messages: - JDK-8334618 Changes: https://git.openjdk.org/jdk/pull/19802/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19802=00 Issue: https://bugs.openjdk.org/browse/JDK-8334618 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/19802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19802/head:pull/19802 PR: https://git.openjdk.org/jdk/pull/19802
Integrated: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure > flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime > error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not > crash and it was not noticed before. This pull request has now been integrated. Changeset: abbf45b5 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/abbf45b57edf2f5bf9a3f2fa408f35a43ebe9bb9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' Reviewed-by: jbechberger, stuefe - PR: https://git.openjdk.org/jdk/pull/19628
Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure > flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime > error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not > crash and it was not noticed before. Hi Thomas and Johannes, thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2162188598
Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr
> this oob error can be seen :
>
> /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime
> error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
> #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId)
> /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31
> #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool)
> /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47
>
> Looks like the array in generated code is too small.
> With
> `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];`
> and
>
> static const int NUMBER_OF_EVENTS = 162;
> static const int NUMBER_OF_RESERVED_EVENTS = 2;
>
>
> Access at index 163 cannot work.
> But it looks like there is always enough memory after the array so we do not
> crash and it was not noticed before.
My maximum JfrEventId is 163 , see the generated
hotspot/variant-server/gensrc/jfrfiles/jfrEventIds.hpp
enum JfrEventId {
JfrMetadataEvent = 0,
JfrCheckpointEvent = 1,
JfrDurationEvent = 2,
JfrInstantEvent = 3,
JfrValueEvent = 4,
JfrTextEvent = 5,
JfrZThreadDebugEvent = 6,
.
JfrJavaAgentEvent = 161,
JfrNativeAgentEvent = 162,
JfrDeprecatedInvocationEvent = 163,
};
so NUMBER_OF_EVENTS + NUMBER_OF_RESERVED_EVENTS looks fine to me.
163 is the highest I could see while testing.
-
PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2160953294
RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr this oob error can be seen : /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 Looks like the array in generated code is too small. With `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` and static const int NUMBER_OF_EVENTS = 162; static const int NUMBER_OF_RESERVED_EVENTS = 2; Access at index 163 cannot work. But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. - Commit messages: - JDK-8332699 Changes: https://git.openjdk.org/jdk/pull/19628/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19628=00 Issue: https://bugs.openjdk.org/browse/JDK-8332699 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19628/head:pull/19628 PR: https://git.openjdk.org/jdk/pull/19628
Integrated: 8331298: avoid alignment checks in UBSAN enabled build
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote: > Currently we run into some alignment related issues when building with > '--enable-ubsan' . Those errors already occur in the build. Fixing them might > take some time and maybe also some discussion if it is worth the effort , > So for now the alignment related checks should be disabled to get the UBSAN > build working. > Example : > > /jdk/src/hotspot/cpu/x86/macroAssembler_x86.hpp:128:13: runtime error: store > to misaligned address 0x15099c3cf4ce for type 'int', which requires 4 byte > alignment > 0x15099c3cf4ce: note: pointer points here > 00 80 0f 86 00 00 00 00 3d 06 00 00 80 76 60 3d 07 00 00 80 76 40 3d 08 00 > 00 80 76 20 3d 1e 00 > ^ > #0 0x1509b3b04f10 in MacroAssembler::pd_patch_instruction(unsigned char*, > unsigned char*, char const*, int) > /jdk/src/hotspot/cpu/x86/macroAssembler_x86.hpp:128 > #1 0x1509b3b04f10 in Label::patch_instructions(MacroAssembler*) > /jdk/src/hotspot/share/asm/assembler.cpp:201 > #2 0x1509b940b6d8 in VM_Version_StubGenerator::generate_get_cpu_info() > /jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:381 > #3 0x1509b94059bd in VM_Version::initialize() > /jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:2138 > #4 0x1509b93fb56e in VM_Version_init() > /jdk/src/hotspot/share/runtime/vm_version.cpp:32 > #5 0x1509b61ef947 in init_globals() > /jdk/src/hotspot/share/runtime/init.cpp:126 > #6 0x1509b8fb0e29 in Threads::create_vm(JavaVMInitArgs*, bool*) > /jdk/src/hotspot/share/runtime/threads.cpp:553 > #7 0x1509b67da3d7 in JNI_CreateJavaVM_inner > /jdk/src/hotspot/share/prims/jni.cpp:3581 > #8 0x1509b67da3d7 in JNI_CreateJavaVM > /jdk/src/hotspot/share/prims/jni.cpp:3672 > #9 0x1509c0eed957 in InitializeJVM > /jdk/src/java.base/share/native/libjli/java.c:1550 > #10 0x1509c0eed957 in JavaMain > /jdk/src/java.base/share/native/libjli/java.c:491 > ... (rest of output omitted) This pull request has now been integrated. Changeset: 60b61e58 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/60b61e588c1252b4b1fbc64d0f818a85670f7146 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8331298: avoid alignment checks in UBSAN enabled build Reviewed-by: erikj, mdoerr - PR: https://git.openjdk.org/jdk/pull/18998
Re: RFR: 8331298: avoid alignment checks in UBSAN enabled build
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote: > Currently we run into some alignment related issues when building with > '--enable-ubsan' . Those errors already occur in the build. Fixing them might > take some time and maybe also some discussion if it is worth the effort , > So for now the alignment related checks should be disabled to get the UBSAN > build working. > Example : > > /jdk/src/hotspot/cpu/x86/macroAssembler_x86.hpp:128:13: runtime error: store > to misaligned address 0x15099c3cf4ce for type 'int', which requires 4 byte > alignment > 0x15099c3cf4ce: note: pointer points here > 00 80 0f 86 00 00 00 00 3d 06 00 00 80 76 60 3d 07 00 00 80 76 40 3d 08 00 > 00 80 76 20 3d 1e 00 > ^ > #0 0x1509b3b04f10 in MacroAssembler::pd_patch_instruction(unsigned char*, > unsigned char*, char const*, int) > /jdk/src/hotspot/cpu/x86/macroAssembler_x86.hpp:128 > #1 0x1509b3b04f10 in Label::patch_instructions(MacroAssembler*) > /jdk/src/hotspot/share/asm/assembler.cpp:201 > #2 0x1509b940b6d8 in VM_Version_StubGenerator::generate_get_cpu_info() > /jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:381 > #3 0x1509b94059bd in VM_Version::initialize() > /jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:2138 > #4 0x1509b93fb56e in VM_Version_init() > /jdk/src/hotspot/share/runtime/vm_version.cpp:32 > #5 0x1509b61ef947 in init_globals() > /jdk/src/hotspot/share/runtime/init.cpp:126 > #6 0x1509b8fb0e29 in Threads::create_vm(JavaVMInitArgs*, bool*) > /jdk/src/hotspot/share/runtime/threads.cpp:553 > #7 0x1509b67da3d7 in JNI_CreateJavaVM_inner > /jdk/src/hotspot/share/prims/jni.cpp:3581 > #8 0x1509b67da3d7 in JNI_CreateJavaVM > /jdk/src/hotspot/share/prims/jni.cpp:3672 > #9 0x1509c0eed957 in InitializeJVM > /jdk/src/java.base/share/native/libjli/java.c:1550 > #10 0x1509c0eed957 in JavaMain > /jdk/src/java.base/share/native/libjli/java.c:491 >... (rest of output omitted) Thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/18998#issuecomment-2084588114
RFR: 8331298: avoid alignment checks in UBSAN enabled build
Currently we run into some alignment related issues when building with '--enable-ubsan' . Those errors already occur in the build. Fixing them might take some time and maybe also some discussion if it is worth the effort , So for now the alignment related checks should be disabled to get the UBSAN build working. Example : /jdk/src/hotspot/cpu/x86/macroAssembler_x86.hpp:128:13: runtime error: store to misaligned address 0x15099c3cf4ce for type 'int', which requires 4 byte alignment 0x15099c3cf4ce: note: pointer points here 00 80 0f 86 00 00 00 00 3d 06 00 00 80 76 60 3d 07 00 00 80 76 40 3d 08 00 00 80 76 20 3d 1e 00 ^ #0 0x1509b3b04f10 in MacroAssembler::pd_patch_instruction(unsigned char*, unsigned char*, char const*, int) /jdk/src/hotspot/cpu/x86/macroAssembler_x86.hpp:128 #1 0x1509b3b04f10 in Label::patch_instructions(MacroAssembler*) /jdk/src/hotspot/share/asm/assembler.cpp:201 #2 0x1509b940b6d8 in VM_Version_StubGenerator::generate_get_cpu_info() /jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:381 #3 0x1509b94059bd in VM_Version::initialize() /jdk/src/hotspot/cpu/x86/vm_version_x86.cpp:2138 #4 0x1509b93fb56e in VM_Version_init() /jdk/src/hotspot/share/runtime/vm_version.cpp:32 #5 0x1509b61ef947 in init_globals() /jdk/src/hotspot/share/runtime/init.cpp:126 #6 0x1509b8fb0e29 in Threads::create_vm(JavaVMInitArgs*, bool*) /jdk/src/hotspot/share/runtime/threads.cpp:553 #7 0x1509b67da3d7 in JNI_CreateJavaVM_inner /jdk/src/hotspot/share/prims/jni.cpp:3581 #8 0x1509b67da3d7 in JNI_CreateJavaVM /jdk/src/hotspot/share/prims/jni.cpp:3672 #9 0x1509c0eed957 in InitializeJVM /jdk/src/java.base/share/native/libjli/java.c:1550 #10 0x1509c0eed957 in JavaMain /jdk/src/java.base/share/native/libjli/java.c:491 ... (rest of output omitted) - Commit messages: - JDK-8331298 Changes: https://git.openjdk.org/jdk/pull/18998/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18998=00 Issue: https://bugs.openjdk.org/browse/JDK-8331298 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18998/head:pull/18998 PR: https://git.openjdk.org/jdk/pull/18998
Re: RFR: 8314488: Compile the JDK as C++17 [v7]
On Wed, 20 Mar 2024 05:44:48 GMT, Julian Waters wrote: >> Compile the JDK as C++17, enabling the use of all C++17 language features > > Julian Waters has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into patch-7 > - Require clang 13 in toolchain.m4 > - Remove unnecessary -std=c++17 option in Lib.gmk > - Merge branch 'openjdk:master' into patch-7 > - Compiler versions in toolchain.m4 > - Merge branch 'openjdk:master' into patch-7 > - Merge branch 'openjdk:master' into patch-7 > - Revert vm_version_linux_riscv.cpp > - vm_version_linux_riscv.cpp > - allocation.cpp > - ... and 1 more: https://git.openjdk.org/jdk/compare/269163d5...9286a964 Seems we use already a little bit of C++17 coding in the Linux codebase . Just came across this little error when trying to build with clang on Linux jdk/src/hotspot/os/linux/os_linux.cpp:2975:65: error: 'static_assert' with no message is a C++17 extension [-Werror,-Wc++17-extensions] static_assert(MADV_POPULATE_WRITE == MADV_POPULATE_WRITE_value); So switching to C++17 would make our codebase compile :-) (at least in this case) ! (to be more serious, I guess I better file a JBS bug and post a PR/fix for this static_assert) - PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-2061233028
Re: RFR: 8330110: AIX build fails after JDK-8329704 - issue with libjli.a
On Fri, 12 Apr 2024 12:26:06 GMT, Magnus Ihse Bursie wrote: > Unfortunately, after > [JDK-8329704](https://bugs.openjdk.org/browse/JDK-8329704) AIX fails to > build. The reason is that libjli is specially treated on AIX, and built like > a static library. I tried to compensate for this (and had tested on an > earlier draft), but some late-minute changes in JDK-8329704 made this check > fail. > > At this point, I will not add any more checks for `$1_$2_STATIC_LIBRARY` in > `ResolveLibPath`. From reading the code, it become apparent that building > with `STATIC_BUILD` (n.b. -- not `STATIC_LIBS`!) will likely fail. This has > on the other hand not been tested for a long time, and is likely bit-rotten > anyway. Also, I will very soon address all of these shortcomings in the > upcoming rewrite for proper static builds. This resolves the AIX build problem. - Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18759#pullrequestreview-1997232221
Re: RFR: 8329131: Fold libjli_static back into libjli on AIX
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote: > On AIX, we need a static libjli, since the linker cannot find other libraries > (like libjvm.so and libjava.so) using a relative path, as on other platforms. > > However, for reasons unclear, we still build a dynamic libjli.so on AIX, even > though this is never used. Instead, we also build a static libjli_static.a > library (which is then forced to have a different name as to not collide with > the dynamic library). > > This should be fixed. We should build exactly one libjli on all platforms, be > it static or dynamic. Unfortunately the AIX build fails with this patch * For target support_test_jdk_jtreg_native_support_exeJliLaunchTest_BUILD_TEST_exeJliLaunchTest_link: ld: 0706-006 Cannot find or open library file: -l jli ld:open(): No such file or directory .ibm-clang: error: linker command failed with exit code 255 (use -v to see invocation) - PR Comment: https://git.openjdk.org/jdk/pull/18497#issuecomment-2024638873
Re: RFR: JDK-8329074: AIX build fails after JDK-8328824
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
> /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o]
> Error 2
> gmake[3]: *** Waiting for unfinished jobs
>
> Looks like an addprefix usage is wrong, a '$' is missing.
windows aarch64 failure is unrelated, fails with some download
[build.sh][INFO] Downloading
https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.8-bin.zip to
/d/a/jdk/jdk/jtreg/src/make/../build/deps/apache-ant-1.10.8-bin.zip
Error: sh][ERROR] wget exited with exit code 4
Thanks for the reviews !
-
PR Comment: https://git.openjdk.org/jdk/pull/18484#issuecomment-2019994055
PR Comment: https://git.openjdk.org/jdk/pull/18484#issuecomment-2019997165
Integrated: JDK-8329074: AIX build fails after JDK-8328824
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
> /openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o]
> Error 2
> gmake[3]: *** Waiting for unfinished jobs
>
> Looks like an addprefix usage is wrong, a '$' is missing.
This pull request has now been integrated.
Changeset: b9c76ded
Author:Matthias Baesken
URL:
https://git.openjdk.org/jdk/commit/b9c76dedf4aa2248a5e561a535c9e3e181f7836a
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
8329074: AIX build fails after JDK-8328824
Reviewed-by: clanger, goetz
-
PR: https://git.openjdk.org/jdk/pull/18484
RFR: JDK-8329074: AIX build fails after JDK-8328824
After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the
AIX build into this failure :
/opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
gmake[3]: *** [lib/CoreLibraries.gmk:194:
/openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_static/args.o]
Error 2
gmake[3]: *** Waiting for unfinished jobs
Looks like an addprefix usage is wrong, a '$' is missing.
-
Commit messages:
- JDK-8329074
Changes: https://git.openjdk.org/jdk/pull/18484/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18484=00
Issue: https://bugs.openjdk.org/browse/JDK-8329074
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/18484.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/18484/head:pull/18484
PR: https://git.openjdk.org/jdk/pull/18484
Re: RFR: 8327701: Remove the xlc toolchain [v4]
On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie wrote: >> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building >> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect >> clang by another name, and it uses the clang toolchain in the JDK build. >> Thus the old xlc toolchain is no longer supported, and should be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with two > additional commits since the last revision: > > - Replace CC_VERSION_OUTPUT with CC_VERSION_STRING > - We need CC_VERSION_OUTPUT before we can check it Seems `HOTSPOT_TOOLCHAIN_TYPE=xlc ` and `TARGET_COMPILER_xlc` macros stay, is this intended ? (not saying this is a wrong thing to do, but I believed first that all the xlc toolchain references are replaced by clang?) - PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1993844670
Re: RFR: 8327701: Remove the xlc toolchain [v2]
On Tue, 12 Mar 2024 16:02:41 GMT, Matthias Baesken wrote: > > Please re-test. > > Hi Magnus, thanks for the adjustments. I reenabled your patch in our > build/test queue . Builds and test results on AIX (product and fastdebug) are fine with the latest version of the PR . - PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1993808324
Re: RFR: 8327701: Remove the xlc toolchain [v2]
On Tue, 12 Mar 2024 15:24:21 GMT, Magnus Ihse Bursie wrote: > Please re-test. Hi Magnus, thanks for the adjustments. I reenabled your patch in our build/test queue . - PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1992009593
Re: RFR: 8327701: Remove the xlc toolchain [v2]
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote: >> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building >> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect >> clang by another name, and it uses the clang toolchain in the JDK build. >> Thus the old xlc toolchain is no longer supported, and should be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Revert SEARCH_PATH changes With this change added, currently configure fails checking for ibm-llvm-cxxfilt... /opt/IBM/openxlC/17.1.1/tools/ibm-llvm-cxxfilt configure: error: ibm-clang_r version output check failed, output: configure exiting with result code maybe related to what Joachim pointed out ? - PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1988358518
Re: RFR: 8327701: Remove the xlc toolchain [v2]
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote: >> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building >> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect >> clang by another name, and it uses the clang toolchain in the JDK build. >> Thus the old xlc toolchain is no longer supported, and should be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Revert SEARCH_PATH changes Hi, thanks for doing this cleanup change. I put it into our build/test queue to see the results on AIX. - PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1987807579
Re: RFR: 8017234: Hotspot should stop using mapfiles [v5]
On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie wrote: > > We had the PR in our SAP internal build/test queue, so issues seen with it. > > What issues did you see? Or was that a typo for "no issues"? Sorry Magnus, tests were fine no issues were observed. - PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961250951
Re: RFR: 8017234: Hotspot should stop using mapfiles [v5]
On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie wrote: > Just to confirm: this PR passes tier 1-5. We had the PR in our SAP internal build/test queue, so issues seen with it. - PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote: >>> I hope finally the AIX part of this PR is done. >> >> Thanks for the AIX related effort ; I put it again into our internal >> build/test queue. > >> >> Thanks for the AIX related effort ; I put it again into our internal >> build/test queue. > > With the latest commit the build again fails on AIX with this error > > /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: > error: incompatible pointer types passing 'struct statvfs64 *' to parameter > of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] > result = fstatvfs(fd, _stat); > ^~ > /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here > extern int fstatvfs(int, struct statvfs *); > Well, well... The code at least looks cleaner without these AIX defines, so I > really hope that this is the end of the AIX saga, at the `n+1`th time. > @MBaesken Can you rerun AIX testing with the latest commit? Latest commit looks still good on AIX. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933652124
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we >> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK >> native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Also fix fstatvfs on AIX AIX build is fixed now after latest commit, thanks for handling the AIX special cases. - Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1865270571
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote: > > Thanks for the AIX related effort ; I put it again into our internal > build/test queue. With the latest commit the build again fails on AIX with this error /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] result = fstatvfs(fd, _stat); ^~ /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here extern int fstatvfs(int, struct statvfs *); - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928972961
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote: > I hope finally the AIX part of this PR is done. Thanks for the AIX related effort ; I put it again into our internal build/test queue. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote: > It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have > not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef > _ALLBSD_SOURCE`, which I presume is not defined on AIX. > > I recommend that I push this PR as-is first, and then you can do a follow-up > fix to define statvfs to statvfs64 on AIX. Java_sun_nio_fs_UnixNativeDispatcher_statvfs0 is changed from statvfs64 to statvfs, did I miss something ? - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926925394
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote: > Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on > AIX to 32-Bit. _LARGE_FILES really does not help in this case! Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64 variant needs to stay on AIX. Seems the other symbols are covered by _LARGE_FILES according to the table in the linked IBM AIX doc (table in https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files ) , is that correct (Joachim?) or did I miss something ? - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926874075
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we >> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK >> native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926848063
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we >> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK >> native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I noticed that in the file src/java.base/share/native/libzip/zlib/zconf.h we seem to still use `off64_t` , is this okay (at most other locations it was replaced) https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libzip/zlib/zconf.h#L541 - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926448109
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to >> admit it does not look very nice). >> >> >> diff --git >> a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in >> [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) >> did not help? Maybe then it is some other system library that drags in >> `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way >> too much that it does not need, so we can surely strip it of even more >> standard includes if that is what is required to fix this. > > > Unfortunately it did not help. > @MBaesken How annoying. :( I have now tried to remove _all_ system includes > from `debug_util.h`. Can you please try again building debug on AIX, to see > if it works without the `#undef` in `BufferedRenderPipe.c`? The AIX (fast)debug build still fails . - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921645170
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due >> to a merge or a rebase. The incremental webrev excludes the unrelated >> changes brought in by the merge/rebase. The pull request contains seven >> additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to > admit it does not look very nice). > > > diff --git > a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 > @MBaesken So my fix in > [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) > did not help? Maybe then it is some other system library that drags in > `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way > too much that it does not need, so we can surely strip it of even more > standard includes if that is what is required to fix this. Unfortunately it did not help. - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921367368
Re: RFR: 8324834: Use _LARGE_FILES on AIX [v2]
On Thu, 1 Feb 2024 09:04:47 GMT, Magnus Ihse Bursie wrote: > I added a compile-time check that hotspot on AIX is indeed compiled with > _LARGE_FILES. > > @MBaesken Are you happy with this PR now? Thanks for adding this, I approved the PR . - PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1921204582
Re: RFR: 8324834: Use _LARGE_FILES on AIX [v2]
On Tue, 30 Jan 2024 12:25:47 GMT, Magnus Ihse Bursie wrote: >> In the same spirit as >> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt >> the AIX-specific code in hotspot so it uses the well-defined posix `` >> functions, instead of `64`. By setting the define _LARGE_FILES, this >> will make `` behave as `64`, just as _FILE_OFFSET_BITS=64 does on >> gcc. (Reference: >> https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files) >> >> In theory, it should not even be necessary to set this, since we only >> compile for 64-bit AIX platforms, and this is only relevant on 32-bit >> platforms. But let's add the define anyway, for good measure. It shows at >> least that we have thought about the matter. :-) >> >> I have not been able to test this on AIX. I hope someone with AIX access can >> take this for a spin. >> >> The reason I'm doing this is for >> [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these >> bugs are fixed, there will be no more `64` function calls in the code >> base. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Revert "8324753: [AIX] adjust os_posix after JDK-8318696" > > This reverts commit 8950d68ddb36d35831fbb4b98969cd0537527070. Marked as reviewed by mbaesken (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17611#pullrequestreview-1855922518
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4]
On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we >> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK >> native libraries. > > Magnus Ihse Bursie has updated the pull request with a new target base due to > a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains seven additional > commits since the last revision: > > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - Restore AIX dirent64 et al defines > - Rollback AIX changes since they are now tracked in JDK-8324834 > - Remove superfluous setting of FOB64 > - Replace all foo64() with foo() for large-file functions in the JDK > - 8324539: Do not use LFS64 symbols in JDK libs After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c index 823475b0a23..ee0109b6806 100644 --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c @@ -31,6 +31,10 @@ #include "SpanIterator.h" #include "Trace.h" +#if defined(_AIX) && defined(open) +#undef open +#endif + /* The "header" consists of a jint opcode and a jint span count value */ #define INTS_PER_HEADER 2 #define BYTES_PER_HEADER 8 - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918699480
Re: RFR: 8324834: Use _LARGE_FILES on AIX [v2]
On Wed, 31 Jan 2024 08:49:58 GMT, Magnus Ihse Bursie wrote: > I suspect this worry of yours were more directed at the change for the JDK Yes it is more a general worry, not especially related to Hotspot. We could also add some kind of check (e.g. static assert or configure check) to address it. - PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1918679294
Re: RFR: 8324834: Use _LARGE_FILES on AIX
On Mon, 29 Jan 2024 13:13:44 GMT, Matthias Baesken wrote: >> In the same spirit as >> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt >> the AIX-specific code in hotspot so it uses the well-defined posix `` >> functions, instead of `64`. By setting the define _LARGE_FILES, this >> will make `` behave as `64`, just as _FILE_OFFSET_BITS=64 does on >> gcc. (Reference: >> https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files) >> >> In theory, it should not even be necessary to set this, since we only >> compile for 64-bit AIX platforms, and this is only relevant on 32-bit >> platforms. But let's add the define anyway, for good measure. It shows at >> least that we have thought about the matter. :-) >> >> I have not been able to test this on AIX. I hope someone with AIX access can >> take this for a spin. >> >> The reason I'm doing this is for >> [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these >> bugs are fixed, there will be no more `64` function calls in the code >> base. > > Using the '_LARGE_FILES' should be okay, I checked this in a small example in > the binary and it showed the the 64bit/large file function was used. > Looks good from my end now. I leave the final approval to @MBaesken since he > ran this through our testing I believe. I put it into our build/test queue (so far had only a look at the change). Unfortunately with going away from the 64 functions on AIX, it gets very intransparent. In case we lose the compile flag (or the compile flags gets filtered out/is not set for some compilation unit) we silently fall back to "short files" support instead of "large files" support. https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files "It has the disadvantage of creating some ambiguity in the code because the size of the various data items cannot be determined from looking at the code" - PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1918611708
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs
On Tue, 30 Jan 2024 13:54:45 GMT, Magnus Ihse Bursie wrote: > I'd appreciate if you could take the latest version for a spin, particularly > a debug build... Yes we pick up the latest version of the PR in a couple of hours for the build+'lots of tests' (and this includes a fastdebug too). - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1916925827
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs
On Tue, 30 Jan 2024 13:02:53 GMT, Magnus Ihse Bursie wrote: > @MBaesken You gotta be kidding me... They just put in a `#define open open64` > in a convenient place?  > > But why do only slowdebug fail? Weird. Yes there is a nice define in the AIX header ifdef _LARGE_FILES #define openopen64 Why only fastdebug (we build product and fastdebug nightly) - no idea . - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1916881475
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we > should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK > native libraries. AIX fastdebug build fails with the patch, build error is /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-dbg/jdk/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c:101:24: error: no member named 'open64' in 'SpanIteratorFuncs'; did you mean 'open'? srData = (*pFuncs->open)(env, si); ^~~~ open /usr/include/fcntl.h:115:14: note: expanded from macro 'open' #define openopen64 ^ /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-dbg/jdk/src/java.desktop/share/native/libawt/java2d/pipe/SpanIterator.h:37:17: note: 'open' declared here void *(*open)(JNIEnv *env, jobject iterator); - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1916295477
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs
On Mon, 29 Jan 2024 13:54:35 GMT, Joachim Kern wrote: > Why not CFLAGS_OS_DEF_JVM="-DAIX -D_LARGE_FILES" as the equivalent on Linux I think this PR is intended to be just about the JDK libs, not JVM compilation. - PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1469835487
Re: RFR: 8324539: Do not use LFS64 symbols in JDK libs
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we > should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK > native libraries. I put it into our build/test patch list to see how it behaves on your environments (especially AIX). - PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1914724741
Re: RFR: 8324834: Use _LARGE_FILES on AIX
On Mon, 29 Jan 2024 11:44:34 GMT, Magnus Ihse Bursie wrote: > In the same spirit as > [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt > the AIX-specific code in hotspot so it uses the well-defined posix `` > functions, instead of `64`. By setting the define _LARGE_FILES, this > will make `` behave as `64`, just as _FILE_OFFSET_BITS=64 does on > gcc. (Reference: > https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files) > > In theory, it should not even be necessary to set this, since we only compile > for 64-bit AIX platforms, and this is only relevant on 32-bit platforms. But > let's add the define anyway, for good measure. It shows at least that we have > thought about the matter. :-) > > I have not been able to test this on AIX. I hope someone with AIX access can > take this for a spin. > > The reason I'm doing this is for > [JDK-8324539](https://bugs.openjdk.org/browse/JDK-8324539). After both these > bugs are fixed, there will be no more `64` function calls in the code > base. > I believe this has missed 2 callsites in os_posix.cpp, which recently swapped > to the 64 suffixed variant that is controlled the AIX_ONLY macro #17587 Yes the 2 changes 'overlapped' . Using the '_LARGE_FILES' should be okay, I checked this in a small example in the binary and it showed the the 64bit/large file function was used. - PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1914669910 PR Comment: https://git.openjdk.org/jdk/pull/17611#issuecomment-1914672408
Re: RFR: 8318696: Do not use LFS64 symbols on Linux [v5]
On Mon, 22 Jan 2024 12:19:25 GMT, Sam James wrote: > Could someone run the other commands again for older branches for me as well? > I don't have access. Will look into 17 as well. Might make sense to have some other minor backports to jdk17u-dev before, to make the backport easier (maybe [almost] clean) . - PR Comment: https://git.openjdk.org/jdk/pull/16329#issuecomment-1905617230
Re: RFR: 8318696: Do not use LFS64 symbols on Linux [v4]
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote: >> The LFS64 symbols provided by glibc are not part of any standard and were >> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5). >> This commit replaces the usage of LFS64 symbols with their regular >> counterparts and defines -D_FILE_OFFSET_BITS=64, ensuring that functions >> will always act as their -64 variants on glibc. > > Sam James has updated the pull request incrementally with two additional > commits since the last revision: > > - sendfile64 -> sendfile > >Signed-off-by: Sam James > - buf64->buf > >Signed-off-by: Sam James Looks good to me, but please also adjust COPYRIGHT headers (e.g. flags-cflags.m4) . Btw. I can confirm that with your patch applied, the build is fixed on Alpine 3.19 (see also [JDK-8324153](https://bugs.openjdk.org/browse/JDK-8324153) build fails on Alpine x86_64 3.19 for details on the failures) . - Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16329#pullrequestreview-1832719082
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Fri, 12 Jan 2024 13:32:28 GMT, Julian Waters wrote: >As I mentioned above, the autoconf inserting of those compiler flags can be >disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly empty >values. It's also a workaround, but is slightly less hacky than filtering out >the CXX values >like this. Maybe a topic for another changeset? Yes maybe something for another changeset . [RealCLanger](https://github.com/RealCLanger) did you try this, maybe you mentioned something like this ? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889234006
Integrated: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote: > It was observed, that autoconf 2.72 added on macOS x86_64 the flag > -std=gnu++11 by default to CXX in the configure process . > This is not really wanted so better remove / filter out those -std* flags > added by autoconf from CXX . > > Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see > TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that > dates back to JDK 9. > > See the discussion about this issue : > https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html This pull request has now been integrated. Changeset: 68c42860 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/68c4286026bc2c0ec0f594e0b96fe03fe5624d6d Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod 8323008: filter out harmful -std* flags added by autoconf from CXX Reviewed-by: erikj, clanger, ihse - PR: https://git.openjdk.org/jdk/pull/17301
Re: RFR: JDK-8323008: filter out harmful -std* flags added by autoconf from CXX [v4]
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote: >> It was observed, that autoconf 2.72 added on macOS x86_64 the flag >> -std=gnu++11 by default to CXX in the configure process . >> This is not really wanted so better remove / filter out those -std* flags >> added by autoconf from CXX . >> >> Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see >> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that >> dates back to JDK 9. >> >> See the discussion about this issue : >> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust GREP, remove unneeded test Thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1889055298
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX [v4]
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote: >> It was observed, that autoconf 2.72 added on macOS x86_64 the flag >> -std=gnu++11 by default to CXX in the configure process . >> This is not really wanted so better remove / filter out any -std* flags >> added by autoconf from CC/CXX . >> >> Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see >> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that >> dates back to JDK 9. >> >> See the discussion about this issue : >> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust GREP, remove unneeded test Erik (and Magnus?) are you okay with the latest version of the patch ? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1888588338
Re: RFR: 8314488: Compile the JDK as C++17 [v6]
On Fri, 12 Jan 2024 06:32:34 GMT, Kim Barrett wrote: > > Thanks! We may switch to clang 14 on MacOS at some point of time, but it's > > better to have that disentangled. Some people build JDK 11 and 23 on the > > same machine and that is easier if they don't have to switch Xcode. > > I think the minimum clang version should not be greater than what’s provided > by the minimum Open XL C/C++ version. > > If the aix-ppc port only requires Open XL C/C++ 17.1.1 then that’s clang 13. > If the aix-ppc port were to instead jump further forward, to 17.1.2, then > that’s clang 15. > > I've asked the aix-ppc folks if requiring 17.1.2 would be okay, but haven't > heard back yet. We at SAP use and document xlC 17.1.1.4 for jdk22 (use the same for jdk23) https://wiki.openjdk.org/display/Build/Supported+Build+Platforms version 17.1.1.4 is already clang15 (at least that's what the compiler output is telling me) /opt/IBM/openxlC/17.1.1/bin/ibm-clang++_r -v IBM Open XL C/C++ for AIX 17.1.1 (5725-C72, 5765-J18), version 17.1.1.4, clang version 15.0.0 (build ca7115e) Target: powerpc-ibm-aix7.2.0.0 - PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1888583559
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX
On Thu, 11 Jan 2024 13:54:01 GMT, Christoph Langer wrote: > Makes sense. It's the same pattern. I adjusted the second GREP too and removed the` if test` . - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1887318284
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX [v4]
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag > -std=gnu++11 by default to CXX in the configure process . > This is not really wanted so better remove / filter out any -std* flags added > by autoconf from CC/CXX . > > Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see > TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that > dates back to JDK 9. > > See the discussion about this issue : > https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust GREP, remove unneeded test - Changes: - all: https://git.openjdk.org/jdk/pull/17301/files - new: https://git.openjdk.org/jdk/pull/17301/files/98046dfc..2ae6e0c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17301=03 - incr: https://webrevs.openjdk.org/?repo=jdk=17301=02-03 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17301/head:pull/17301 PR: https://git.openjdk.org/jdk/pull/17301
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX [v3]
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag > -std=gnu++11 by default to CXX in the configure process . > This is not really wanted so better remove / filter out any -std* flags added > by autoconf from CC/CXX . > > Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see > TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that > dates back to JDK 9. > > See the discussion about this issue : > https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust COPYRIGHT year - Changes: - all: https://git.openjdk.org/jdk/pull/17301/files - new: https://git.openjdk.org/jdk/pull/17301/files/63300451..98046dfc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17301=02 - incr: https://webrevs.openjdk.org/?repo=jdk=17301=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17301/head:pull/17301 PR: https://git.openjdk.org/jdk/pull/17301
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX [v2]
On Thu, 11 Jan 2024 11:19:01 GMT, Magnus Ihse Bursie wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Adjust GREP call > > make/autoconf/toolchain.m4 line 395: > >> 393: # filter out some unwanted additions autoconf may add to CXX; we saw >> this on macOS with autoconf 2.72 >> 394: UTIL_GET_NON_MATCHING_VALUES(cxx_filtered, $CXX, -std=c++11 >> -std=gnu++11) >> 395: if test "x$cxx_filtered" != x; then > > Why this test? If CXX is empty, then xcc_filtered will be empty too, right? > And if CXX is exactly `-std=c++11`, then this test will render cxx_filter > empty too, which will not change CXX -- which I believe is not what you want? Probably you are right; I think I 'borrowed' the pattern with the additional` if test` from some other places where UTIL_GET_NON_MATCHING_VALUES is used (e.g. jvm-features.m4). Should I remove the test ? - PR Review Comment: https://git.openjdk.org/jdk/pull/17301#discussion_r1448847359
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX
On Thu, 11 Jan 2024 11:06:02 GMT, Christoph Langer wrote: > > Strange, I noticed that for some reason the > > UTIL_GET_NON_MATCHING_VALUES(cxx_filtered, $CXX, -std=c++11 -std=gnu++11) > > seems not to remove the flags as expected, did I misinterpret how > > UTIL_GET_NON_MATCHING_VALUES works ? Any ideas ? An `CXX=`echo $CXX | cut > > -d ' ' -f1`` extracted what we want (not sure if we want to do it that way, > > in case we have blanks in the CXX value ? > > Hi Matthias, > > I believe that I've figured out the problem with > UTIL_GET_NON_MATCHING_VALUES. The string `-std=c++11` is interpreted as an > option to GREP. This can be fixed by changing from `$GREP -Fvx > "$legal_values" <<< "$values_to_check"` to `$GREP -Fvx -- "$legal_values" <<< > "$values_to_check"` in [this place in > util.m4](https://github.com/openjdk/jdk/blob/b922f8d45951250b7c39cb179b9bc1a8a6256a9e/make/autoconf/util.m4#L202C5-L202C79). > Note the `--` which marks the end of arguments and signals that > `$legal_values` is the pattern. > > I verified that it works. > > Cheers Christoph Thanks , seems GREP was indeed 'harmed' by the parameters we use here. Btw there is a similar place here where we would run into the same issue https://github.com/openjdk/jdk/blob/b922f8d45951250b7c39cb179b9bc1a8a6256a9e/make/autoconf/util.m4#L229 should I adjust this too ? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1887131296
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX [v2]
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag > -std=gnu++11 by default to CXX in the configure process . > This is not really wanted so better remove / filter out any -std* flags added > by autoconf from CC/CXX . > > Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see > TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that > dates back to JDK 9. > > See the discussion about this issue : > https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust GREP call - Changes: - all: https://git.openjdk.org/jdk/pull/17301/files - new: https://git.openjdk.org/jdk/pull/17301/files/ce2ef781..63300451 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17301=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17301=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17301/head:pull/17301 PR: https://git.openjdk.org/jdk/pull/17301
Re: RFR: 8314488: Compile the JDK as C++17 [v5]
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote: >> Compile the JDK as C++17, enabling the use of all C++17 language features > > Julian Waters has updated the pull request incrementally with one additional > commit since the last revision: > > Remove unnecessary -std=c++17 option in Lib.gmk Hi Martin, probably we can update our devkit if really needed. But https://clang.llvm.org/cxx_status.html states that c++17 is supported for a very long time, so probably clang 13.1 is sufficient too (or is there a real showstopper known with this release) . - PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1884892708
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX
On Tue, 9 Jan 2024 17:03:43 GMT, Julian Waters wrote: > Rather than filtering through the added flags like this, is it possible to > figure out why macOS trips the C++11 heuristic and fix the problem there? That might be a bit tricky, because on my macOS test machine, with a self compiled autoconf 2.72, I did not even get this strange behavior. But it was a different macOS version . So it seems to be a problem of very specific environment. > Failing that, a temporary solution of setting the shell var ac_prog_cc_stdc > to yes might help as a band aid solution, as autoconf does not perform the > check if that is set to anything other than no Can we set this somewhere in the OpenJDK m4 files, would be better for us than on the shell before configure. Should we set this in general , or do we want autoconf to add sometimes flags like these to CXX (or maybe CC) ? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1884339468
Re: RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote: > It was observed, that autoconf 2.72 added on macOS x86_64 the flag > -std=gnu++11 by default to CXX in the configure process . > This is not really wanted so better remove / filter out any -std* flags added > by autoconf from CC/CXX . > > Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see > TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that > dates back to JDK 9. > > See the discussion about this issue : > https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html Strange, I noticed that for some reason the UTIL_GET_NON_MATCHING_VALUES(cxx_filtered, $CXX, -std=c++11 -std=gnu++11) seems not to remove the flags as expected, did I misinterpret how UTIL_GET_NON_MATCHING_VALUES works ? Any ideas ? An `CXX=`echo $CXX | cut -d ' ' -f1`` extracted what we want (not sure if we want to do it that way, in case we have blanks in the CXX value ? - PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1883357259
RFR: JDK-8323008: filter out any -std* flags added by autoconf from CC/CXX
It was observed, that autoconf 2.72 added on macOS x86_64 the flag -std=gnu++11 by default to CXX in the configure process . This is not really wanted so better remove / filter out any -std* flags added by autoconf from CC/CXX . Seems we have something similar for some time for CFLAGS and CXXFLAGS ( see TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that dates back to JDK 9. See the discussion about this issue : https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html - Commit messages: - JDK-8323008 Changes: https://git.openjdk.org/jdk/pull/17301/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17301=00 Issue: https://bugs.openjdk.org/browse/JDK-8323008 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17301/head:pull/17301 PR: https://git.openjdk.org/jdk/pull/17301
Re: RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v20]
On Fri, 3 Nov 2023 14:46:39 GMT, Andrew Haley wrote: >> A bug in GCC causes shared libraries linked with -ffast-math to disable >> denormal arithmetic. This breaks Java's floating-point semantics. >> >> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 >> >> One solution is to save and restore the floating-point control word around >> System.loadLibrary(). This isn't perfect, because some shared library might >> load another shared library at runtime, but it's a lot better than what we >> do now. >> >> However, this fix is not complete. `dlopen()` is called from many places in >> the JDK. I guess the best thing to do is find and wrap them all. I'd like to >> hear people's opinions. > > Andrew Haley has updated the pull request incrementally with one additional > commit since the last revision: > > Delete src/hotspot/os/linux/.#os_linux.cpp This leads now to lots of assertions in the jdk tier4 javax/sound tests on our RHEL 9.3 Linux aarch64 box. Opened https://bugs.openjdk.org/browse/JDK-8319708 8319708: Assertion 'fsetenv didn't work' in jdk tier4 tests after 8295159 on Linux aarch64 RHEL9.3 Unfortunately , the shared libs loaded by the JDK native C code (and the dependencies of those libs) are not covered at all, so it is unclear to me what exactly caused the issue. Maybe some sound-related lib on RHEL ? - PR Comment: https://git.openjdk.org/jdk/pull/10661#issuecomment-1803816232
Integrated: JDK-8318961: increase javacserver connection timeout values and max retry attempts
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote: > Increase javacserver connection timeout values and max retry attempts for > better make stability on some slower machines. This pull request has now been integrated. Changeset: b9983c72 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b9983c72295a31e5f5079bc96c892177fbea3a6e Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8318961: increase javacserver connection timeout values and max retry attempts Reviewed-by: clanger, erikj - PR: https://git.openjdk.org/jdk/pull/16397
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts [v2]
On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken wrote: >> Increase javacserver connection timeout values and max retry attempts for >> better make stability on some slower machines. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS Hi Christoph and Erik, thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/16397#issuecomment-1785134884
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts [v2]
> Increase javacserver connection timeout values and max retry attempts for > better make stability on some slower machines. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS - Changes: - all: https://git.openjdk.org/jdk/pull/16397/files - new: https://git.openjdk.org/jdk/pull/16397/files/314ddfbb..a165403f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=16397=01 - incr: https://webrevs.openjdk.org/?repo=jdk=16397=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16397/head:pull/16397 PR: https://git.openjdk.org/jdk/pull/16397
Re: RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote: > Increase javacserver connection timeout values and max retry attempts for > better make stability on some slower machines. I adjusted the WAIT_BETWEEN_CONNECT_ATTEMPTS; Let's how this works. - PR Comment: https://git.openjdk.org/jdk/pull/16397#issuecomment-1784793547
RFR: JDK-8318961: increase javacserver connection timeout values and max retry attempts
Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines. - Commit messages: - JDK-8318961 Changes: https://git.openjdk.org/jdk/pull/16397/files Webrev: https://webrevs.openjdk.org/?repo=jdk=16397=00 Issue: https://bugs.openjdk.org/browse/JDK-8318961 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16397/head:pull/16397 PR: https://git.openjdk.org/jdk/pull/16397
Integrated: JDK-8316894: make test TEST="jtreg:test/jdk/..." fails on AIX
On Wed, 27 Sep 2023 08:18:45 GMT, Matthias Baesken wrote: > Running jtreg tests with make test, for example > make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX > without setting the number of JOBS manually. > We get this error message: > Error: Bad use of -concurrency > > Log of cmdargs shows : > -vmoption:-Xmx768m > -agentvm > -verbose:fail,error,summary > -retain:fail,error > -concurrency:7.00 > > > So currently a float is used for the concurrency value, seems this is not > supported. > Reason is an old gawk printing float values instead of the needed ints, so > better print ints in the makefile by using %d . This pull request has now been integrated. Changeset: 29348b3c Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/29348b3cf65951e1aacd52c517b6b0d29449a78e Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8316894: make test TEST="jtreg:test/jdk/..." fails on AIX Reviewed-by: ihse, erikj - PR: https://git.openjdk.org/jdk/pull/15941
Re: RFR: JDK-8316894: make test TEST="jtreg:test/jdk/..." fails on AIX [v2]
On Thu, 28 Sep 2023 12:57:07 GMT, Matthias Baesken wrote: >> Running jtreg tests with make test, for example >> make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX >> without setting the number of JOBS manually. >> We get this error message: >> Error: Bad use of -concurrency >> >> Log of cmdargs shows : >> -vmoption:-Xmx768m >> -agentvm >> -verbose:fail,error,summary >> -retain:fail,error >> -concurrency:7.00 >> >> >> So currently a float is used for the concurrency value, seems this is not >> supported. >> Reason is an old gawk printing float values instead of the needed ints, so >> better print ints in the makefile by using %d . > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Add 0.5 to avoid rounding issues Hi Magnus and Erik, thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/15941#issuecomment-1739593418
Re: RFR: JDK-8316894: make test TEST="jtreg:test/jdk/..." fails on AIX [v2]
> Running jtreg tests with make test, for example > make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX > without setting the number of JOBS manually. > We get this error message: > Error: Bad use of -concurrency > > Log of cmdargs shows : > -vmoption:-Xmx768m > -agentvm > -verbose:fail,error,summary > -retain:fail,error > -concurrency:7.00 > > > So currently a float is used for the concurrency value, seems this is not > supported. > Reason is an old gawk printing float values instead of the needed ints, so > better print ints in the makefile by using %d . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add 0.5 to avoid rounding issues - Changes: - all: https://git.openjdk.org/jdk/pull/15941/files - new: https://git.openjdk.org/jdk/pull/15941/files/32531634..8319f695 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15941=01 - incr: https://webrevs.openjdk.org/?repo=jdk=15941=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15941/head:pull/15941 PR: https://git.openjdk.org/jdk/pull/15941
Re: RFR: JDK-8316894: make test TEST="jtreg:test/jdk/..." fails on AIX
On Wed, 27 Sep 2023 17:09:04 GMT, Erik Joelsson wrote: > To work around this, perhaps add 0.5 to c before converting to int? Hi Erik, sure we can do so , I adjusted the change. - PR Comment: https://git.openjdk.org/jdk/pull/15941#issuecomment-1739103028
Re: RFR: JDK-8316894: make test TEST="jtreg:test/jdk/..." fails on AIX
On Wed, 27 Sep 2023 12:15:18 GMT, Magnus Ihse Bursie wrote: > Looks good. Have you verified that this works with nawk as well as old gawk > versions? On AIX I have both nawk and gawk on the machine and both work with the change. On Linux I have just gawk (more recent one) and this works too. - PR Comment: https://git.openjdk.org/jdk/pull/15941#issuecomment-1737516357
RFR: JDK-8316894: make test TEST="jtreg:test/jdk/..." fails on AIX
Running jtreg tests with make test, for example make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX without setting the number of JOBS manually. We get this error message: Error: Bad use of -concurrency Log of cmdargs shows : -vmoption:-Xmx768m -agentvm -verbose:fail,error,summary -retain:fail,error -concurrency:7.00 So currently a float is used for the concurrency value, seems this is not supported. Reason is an old gawk printing float values instead of the needed ints, so better print ints in the makefile by using %d . - Commit messages: - JDK-8316894 Changes: https://git.openjdk.org/jdk/pull/15941/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15941=00 Issue: https://bugs.openjdk.org/browse/JDK-8316894 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15941/head:pull/15941 PR: https://git.openjdk.org/jdk/pull/15941
Re: RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen [v3]
On Mon, 4 Sep 2023 07:40:11 GMT, Matthias Baesken wrote: >> After looking at the build results of a jdk22 build on RHEL 8.4 Linux >> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 >> devkit we observed those unwanted paths in libsplashscreen.so . >> See those objdump and ldd output : >> >> objdump -x ./lib/libsplashscreen.so | grep PATH >> RUNPATH >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN >> >> >> ldd ./lib/libsplashscreen.so >> ldd: warning: you do not have execution permission for >> `./lib/libsplashscreen.so' >> . . . >>libX11.so.6 => >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 >> (0x7fffa392) >>libXext.so.6 => >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 >> (0x7fffa38e) >>. . . >> >> These paths were introduced by the '-R' setting, but it seems to be highly >> dependent on the environment. But the '-R' setting should better be avoided >> anyway when the devkit is used. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > with_x case needs to be handled Hi Erik, thanks for the review ! - PR Comment: https://git.openjdk.org/jdk/pull/15534#issuecomment-1706556893
Integrated: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen
On Fri, 1 Sep 2023 11:02:36 GMT, Matthias Baesken wrote: > After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le > that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 > devkit we observed those unwanted paths in libsplashscreen.so . > See those objdump and ldd output : > > objdump -x ./lib/libsplashscreen.so | grep PATH > RUNPATH > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN > > > ldd ./lib/libsplashscreen.so > ldd: warning: you do not have execution permission for > `./lib/libsplashscreen.so' > . . . >libX11.so.6 => > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 > (0x7fffa392) >libXext.so.6 => > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 > (0x7fffa38e) >. . . > > These paths were introduced by the '-R' setting, but it seems to be highly > dependent on the environment. But the '-R' setting should better be avoided > anyway when the devkit is used. This pull request has now been integrated. Changeset: ed2b4673 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/ed2b4673de6893047407c61f82b5e68741459876 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen Reviewed-by: erikj - PR: https://git.openjdk.org/jdk/pull/15534
Re: RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen [v3]
On Mon, 4 Sep 2023 07:40:11 GMT, Matthias Baesken wrote: >> After looking at the build results of a jdk22 build on RHEL 8.4 Linux >> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 >> devkit we observed those unwanted paths in libsplashscreen.so . >> See those objdump and ldd output : >> >> objdump -x ./lib/libsplashscreen.so | grep PATH >> RUNPATH >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN >> >> >> ldd ./lib/libsplashscreen.so >> ldd: warning: you do not have execution permission for >> `./lib/libsplashscreen.so' >> . . . >>libX11.so.6 => >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 >> (0x7fffa392) >>libXext.so.6 => >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 >> (0x7fffa38e) >>. . . >> >> These paths were introduced by the '-R' setting, but it seems to be highly >> dependent on the environment. But the '-R' setting should better be avoided >> anyway when the devkit is used. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > with_x case needs to be handled Hi Erik, are you fine with the latest revision ? - PR Comment: https://git.openjdk.org/jdk/pull/15534#issuecomment-1706097969
Re: RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen [v2]
On Fri, 1 Sep 2023 16:55:21 GMT, Erik Joelsson wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> check for SYSROOT and xlib-setting > > make/autoconf/lib-x11.m4 line 38: > >> 36: X_LIBS= >> 37: else >> 38: x_libraries_orig="$x_libraries" > > This needs to capture the value from `with_x` as well. Both are variants of > user input. Hi Erik, I added a check in the with_x case. - PR Review Comment: https://git.openjdk.org/jdk/pull/15534#discussion_r1314568197
Re: RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen [v3]
> After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le > that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 > devkit we observed those unwanted paths in libsplashscreen.so . > See those objdump and ldd output : > > objdump -x ./lib/libsplashscreen.so | grep PATH > RUNPATH > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN > > > ldd ./lib/libsplashscreen.so > ldd: warning: you do not have execution permission for > `./lib/libsplashscreen.so' > . . . >libX11.so.6 => > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 > (0x7fffa392) >libXext.so.6 => > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 > (0x7fffa38e) >. . . > > These paths were introduced by the '-R' setting, but it seems to be highly > dependent on the environment. But the '-R' setting should better be avoided > anyway when the devkit is used. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: with_x case needs to be handled - Changes: - all: https://git.openjdk.org/jdk/pull/15534/files - new: https://git.openjdk.org/jdk/pull/15534/files/9eb03929..1bed7a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15534=02 - incr: https://webrevs.openjdk.org/?repo=jdk=15534=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15534/head:pull/15534 PR: https://git.openjdk.org/jdk/pull/15534
Re: RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen [v2]
> After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le > that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 > devkit we observed those unwanted paths in libsplashscreen.so . > See those objdump and ldd output : > > objdump -x ./lib/libsplashscreen.so | grep PATH > RUNPATH > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN > > > ldd ./lib/libsplashscreen.so > ldd: warning: you do not have execution permission for > `./lib/libsplashscreen.so' > . . . >libX11.so.6 => > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 > (0x7fffa392) >libXext.so.6 => > /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 > (0x7fffa38e) >. . . > > These paths were introduced by the '-R' setting, but it seems to be highly > dependent on the environment. But the '-R' setting should better be avoided > anyway when the devkit is used. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: check for SYSROOT and xlib-setting - Changes: - all: https://git.openjdk.org/jdk/pull/15534/files - new: https://git.openjdk.org/jdk/pull/15534/files/1d722756..9eb03929 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15534=01 - incr: https://webrevs.openjdk.org/?repo=jdk=15534=00-01 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15534/head:pull/15534 PR: https://git.openjdk.org/jdk/pull/15534
Re: RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen
On Fri, 1 Sep 2023 12:54:45 GMT, Erik Joelsson wrote: >> After looking at the build results of a jdk22 build on RHEL 8.4 Linux >> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 >> devkit we observed those unwanted paths in libsplashscreen.so . >> See those objdump and ldd output : >> >> objdump -x ./lib/libsplashscreen.so | grep PATH >> RUNPATH >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN >> >> >> ldd ./lib/libsplashscreen.so >> ldd: warning: you do not have execution permission for >> `./lib/libsplashscreen.so' >> . . . >>libX11.so.6 => >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 >> (0x7fffa392) >>libXext.so.6 => >> /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 >> (0x7fffa38e) >>. . . >> >> These paths were introduced by the '-R' setting, but it seems to be highly >> dependent on the environment. But the '-R' setting should better be avoided >> anyway when the devkit is used. > > make/autoconf/lib-x11.m4 line 90: > >> 88: fi >> 89: # Also remove the -R setting for devkit usage >> 90: if test "x$with_devkit" != "x" && test "x$with_devkit" != "xno"; then > > This should rather check if `$SYSROOT` has a value and should also check that > `$x_libraries` is `NONE` (see how it's done on line 64). A sysroot can be > configured without a devkit, and if we find the X libraries in the sysroot, > then we shouldn't add an -R path. If however a user needs to specifically > point out the x libraries, I think we need to trust the built in macros as > the user may have them in a non standard place. > > Can we combine the conditionals to avoid having to repeat the if body? Hi Erik, unfortunately `x_libraries` is already modified in the SYSROOT cases (see line 64 and below) , so can I check that `$x_libraries` is `NONE` or should I cache somehow the original value ? - PR Review Comment: https://git.openjdk.org/jdk/pull/15534#discussion_r1313043724
RFR: JDK-8315499: build using devkit on Linux ppc64le RHEL puts path to devkit into libsplashscreen
After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0 devkit we observed those unwanted paths in libsplashscreen.so . See those objdump and ldd output : objdump -x ./lib/libsplashscreen.so | grep PATH RUNPATH /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64:$ORIGIN ldd ./lib/libsplashscreen.so ldd: warning: you do not have execution permission for `./lib/libsplashscreen.so' . . . libX11.so.6 => /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libX11.so.6 (0x7fffa392) libXext.so.6 => /mydevkitsfolder/devkits/ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0/ppc64le-linux-gnu/sysroot/usr/lib64/libXext.so.6 (0x7fffa38e) . . . These paths were introduced by the '-R' setting, but it seems to be highly dependent on the environment. But the '-R' setting should better be avoided anyway when the devkit is used. - Commit messages: - JDK-8315499 Changes: https://git.openjdk.org/jdk/pull/15534/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15534=00 Issue: https://bugs.openjdk.org/browse/JDK-8315499 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15534/head:pull/15534 PR: https://git.openjdk.org/jdk/pull/15534
Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2]
On Mon, 28 Aug 2023 02:26:30 GMT, David Holmes wrote: > Sorry but looking at the hotspot part of this I do not like the code in > jvm.cpp at all - it is far too messy. I expected to see a simple interface to > os::dlopen which then handles all the platform specific issues. > > I'm also somewhat dubious about having all the JDK code use a VM interface > for this, The usual coupling to the VM is to just provide native > implementations of core library methods, not to have the VM provide a general > purpose utility interface like dynamic library loading. Hi David, so would you prefer to call into 'os::dll_load' (probably you meant that) instead ? That would indeed make the coding smaller and less 'messy' . However 'os::dll_load' has no flags parameter but uses a default, have to check if this might be a problem ... - PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1695142975
Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase
On Wed, 23 Aug 2023 12:26:36 GMT, Martin Doerr wrote: > Please check windows-aarch64 build error: unresolved external symbol > dlopen_ext Hi Martin, thanks ! I did a small adjustment, now the windows aarch64 build works. - PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1691148432
Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2]
> Currently there is a number of functionality that would be interesting to > have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see > LoadedLibraries::reload() , see also > https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and > sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: windows aarch64 build issues - Changes: - all: https://git.openjdk.org/jdk/pull/15264/files - new: https://git.openjdk.org/jdk/pull/15264/files/94e25ad7..9ceec5e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15264=01 - incr: https://webrevs.openjdk.org/?repo=jdk=15264=00-01 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264 PR: https://git.openjdk.org/jdk/pull/15264
Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to > have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see > LoadedLibraries::reload() , see also > https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and > sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Hi Phil, yes there are of course more call sites of dlopen in the JDK C codebase. I could cover them too, if this is wished. > . but I'm still not sure I understand .. why is what you are doing only > wanted for the AIX cases ? The lib cache update ` LoadedLibraries::reload();` is AIX specific; the UL and JFR events are cross platform. ( Btw. in our proprietary JVM we have this approach for many years ) - PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678538226
Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to > have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see > LoadedLibraries::reload() , see also > https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and > sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Hi Alan, > JDK-8314152 seems to very AIX specific with shared lib caching that I would > hope complicate interfaces for other ports. yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files. - PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1677045118
RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase
Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. Some examples : Events::log_dll_message for hs-err files reporting JFR event NativeLibraryLoad There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information Offer an interface (e.g. jvm.cpp) to support this. - Commit messages: - JDK-8313764 Changes: https://git.openjdk.org/jdk/pull/15264/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15264=00 Issue: https://bugs.openjdk.org/browse/JDK-8313764 Stats: 150 lines in 7 files changed: 150 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264 PR: https://git.openjdk.org/jdk/pull/15264
Re: RFR: JDK-8313244: NM flags handling in configure process [v4]
On Wed, 9 Aug 2023 15:26:05 GMT, Andreas Steiner wrote: >> On AIX we need the -X64 option for NM in the build. The handling is >> equivalent to the other used tools flags like AR. >> This change will replace the quick fix done in >> https://bugs.openjdk.org/browse/JDK-8312466. > > Andreas Steiner has updated the pull request incrementally with one > additional commit since the last revision: > > add NMFLAGS in NativeCompilation.gmk for consistency Marked as reviewed by mbaesken (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/15150#pullrequestreview-1571163156
Integrated: JDK-8312467: relax the builddir check in make/autoconf/basic.m4
On Tue, 25 Jul 2023 12:00:56 GMT, Matthias Baesken wrote: > In case of issues in the configure step, we run into error messages like this > : > > configure: Current directory is /openjdk/jdk_4/build_mymachine. > configure: Since this is not the source root, configure will output the > configuration here > configure: (as opposed to creating a configuration in > /build/). > configure: However, this directory is not empty. This is not allowed, since > it could > configure: seriously mess up just about everything. > configure: Try 'cd /mysrcdir/jdk' and restart configure > configure: (or create a new empty directory and cd to it). > configure: error: Will not continue creating configuration in > /openjdk/jdk_4/build_mymachine > configure exiting with result code 1 > > Probably the check could be relaxed; it tests for 'if test ! -e > "$OUTPUTDIR/spec.gmk"; then ...' > but the non-existance of spec.gmk does not mean we are not in a build > directory. > We could additionally check for e.g. $OUTPUTDIR/configure-support/config.log > or something related to check if it is a build directory . This pull request has now been integrated. Changeset: 6e3cc131 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6e3cc131daa9f3b883164333bdaad7aa3a6ca018 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8312467: relax the builddir check in make/autoconf/basic.m4 Reviewed-by: clanger, erikj - PR: https://git.openjdk.org/jdk/pull/15017
Re: RFR: JDK-8312467: relax the builddir check in make/autoconf/basic.m4 [v2]
On Wed, 26 Jul 2023 07:21:13 GMT, Matthias Baesken wrote: >> In case of issues in the configure step, we run into error messages like >> this : >> >> configure: Current directory is /openjdk/jdk_4/build_mymachine. >> configure: Since this is not the source root, configure will output the >> configuration here >> configure: (as opposed to creating a configuration in >> /build/). >> configure: However, this directory is not empty. This is not allowed, since >> it could >> configure: seriously mess up just about everything. >> configure: Try 'cd /mysrcdir/jdk' and restart configure >> configure: (or create a new empty directory and cd to it). >> configure: error: Will not continue creating configuration in >> /openjdk/jdk_4/build_mymachine >> configure exiting with result code 1 >> >> Probably the check could be relaxed; it tests for 'if test ! -e >> "$OUTPUTDIR/spec.gmk"; then ...' >> but the non-existance of spec.gmk does not mean we are not in a build >> directory. >> We could additionally check for e.g. $OUTPUTDIR/configure-support/config.log >> or something related to check if it is a build directory . > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust check and output files found in failure case Hi Christoph and Erik, thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/15017#issuecomment-1670787334
Re: RFR: JDK-8313244: NM flags handling in configure process [v2]
On Fri, 4 Aug 2023 11:17:43 GMT, Andreas Steiner wrote:
>> On AIX we need the -X64 option for NM in the build. The handling is
>> equivalent to the other used tools flags like AR.
>> This change will replace the quick fix done in
>> https://bugs.openjdk.org/browse/JDK-8312466.
>
> Andreas Steiner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> remove needless else
make/common/NativeCompilation.gmk uses NM too, is there a reason to avoid the
flag there?
flags-other.m4 : the comment 'on AIX ...' is just stating the obvious; maybe
it should better mention that without -X64 we only process 32bit objects
('Processes only 32-bit object files' says the manpage , and this is the
default on AIX) ; or avoid the comment altogether ?
-
PR Review: https://git.openjdk.org/jdk/pull/15150#pullrequestreview-1562785813
Re: RFR: JDK-8311938: Add default cups include location for configure on AIX [v2]
On Tue, 1 Aug 2023 12:50:47 GMT, Andreas Steiner wrote: >> Add the default include location(/opt/freeware/include/) for cups on AIX. >> With this set the additional configure parameter --with-cups-include can be >> removed, which was needed on AIX. > > Andreas Steiner has updated the pull request incrementally with one > additional commit since the last revision: > > set default cups include location if with_cups is not set only, update > copyright year Moving the check down a bit into a `if test "x$CUPS_FOUND" = xno; then` section might have a little benefit , it would detect cups headers on AIX at the standard location in case a bad non working path has been set with '-with-cups' or 'with-cups-include' . But I am okay with both. - PR Comment: https://git.openjdk.org/jdk/pull/15100#issuecomment-1662124782
