Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v4]
> WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the > binutils and capstone backends, though the LLVM backend is left out due to > compatibility issues encountered during the build. Currently, which gcc > distributions are supported is still to be clarified, as several, ranging > from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, > the build system hack in place at the moment to compile the binutils backend > on Windows is still left in place, for now. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Capstone Support - Add check for compiler in configure - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis - Changes: https://git.openjdk.org/jdk/pull/18915/files Webrev: https://webrevs.openjdk.org/?repo=jdk=18915=03 Stats: 395 lines in 19 files changed: 201 ins; 41 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/18915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915 PR: https://git.openjdk.org/jdk/pull/18915
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. LGTM - Marked as reviewed by jbechberger (Committer). PR Review: https://git.openjdk.org/jdk/pull/19628#pullrequestreview-2108008694
RFR: 8333685: Make update-copyright-year script more useful
Hi all, This PR addresses [8333685](https://bugs.openjdk.org/browse/JDK-8333685). I have added the following enhancements: - Removed uses of `fgrep` and `egrep` with `grep -F` and `grep -E` respectively. - Altered default behaviour to limit the processed changesets to those in the current branch and the current year. - Enabled an option to modify all changesets in the year if desired (this was the previous default behaviour). - Added named parameters and enabled `--help`. - Removed mercurial support. - Fixed a bug where copyright headers that didn't have a comma following the initial year of creation were not getting picked up. For example, [here](https://github.com/openjdk/jdk/blob/512b2b4f141f9a202984150b0427372e1a409a50/src/hotspot/cpu/zero/copy_zero.hpp#L3). - Fixed a bug where copyright headers missing the copyright symbol (c) were not getting picked up. Refer to the example above as well. Thanks, Sonia - Commit messages: - Support for copyright statements missing symbol - 8333685: Make update-copyright-year script more useful Changes: https://git.openjdk.org/jdk/pull/19605/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19605=00 Issue: https://bugs.openjdk.org/browse/JDK-8333685 Stats: 97 lines in 1 file changed: 38 ins; 26 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/19605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19605/head:pull/19605 PR: https://git.openjdk.org/jdk/pull/19605
Re: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v3]
> WIP > > This changeset contains hsdis for Windows/gcc Port. It supports both the > binutils and capstone backends, though the LLVM backend is left out due to > compatibility issues encountered during the build. Currently, which gcc > distributions are supported is still to be clarified, as several, ranging > from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, > the build system hack in place at the moment to compile the binutils backend > on Windows is still left in place, for now. Julian Waters 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 three additional commits since the last revision: - Capstone Support - Add check for compiler in configure - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis - Changes: - all: https://git.openjdk.org/jdk/pull/18915/files - new: https://git.openjdk.org/jdk/pull/18915/files/09fb3d65..b0b088e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=18915=02 - incr: https://webrevs.openjdk.org/?repo=jdk=18915=01-02 Stats: 121745 lines in 2137 files changed: 85534 ins; 24227 del; 11984 mod Patch: https://git.openjdk.org/jdk/pull/18915.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915 PR: https://git.openjdk.org/jdk/pull/18915
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
