Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Tue, 2 Feb 2021 11:56:12 GMT, Vladimir Kempik wrote: > > > > Hello, hsdis is a separate out-of-tree project and is not part of this > > > > jep. > > > > > > > > > Unless there's something I'm missing it only requires a few lines of > > > change to src/utils/hsdis/makefile (it already has support for macos > > > x86_64) > > > > > > I agree with Alan that it makes sense to add this trivial change as part of > > this PR, if it allows the current hsdis solution to continue working on > > mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of > > > > this jep. > > > > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > > > > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has > > been left behind for a long time, and there are several requests to add new > > backends, which require a modernized build of hsdis. This is undfortunately > > not a high-priority project, and has been postponed several times already. > > :( > > Sorry I was under impression hsdis is not part of openjdk tree. > > Alan, could you please share with us the version of binutils you were using > in your test ? > I was just using the latest HEAD: git clone git://sourceware.org/git/binutils-gdb.git src/utils/hsdis/build/binutils A slightly safer approach would be to grab the latest release: https://ftp.gnu.org/gnu/binutils/binutils-2.36.tar.gz Once hsdis-demo was working for me, for only other oddity I had was that the library needed renaming when copying/linking into the build dir: jdk/lib/server/libhsdis-aarch64.dylib - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Tue, 2 Feb 2021 11:14:12 GMT, Vladimir Kempik wrote: > > > > Hello, hsdis is a separate out-of-tree project and is not part of this > > > > jep. > > > > > > > > > Unless there's something I'm missing it only requires a few lines of > > > change to src/utils/hsdis/makefile (it already has support for macos > > > x86_64) > > > > > > I agree with Alan that it makes sense to add this trivial change as part of > > this PR, if it allows the current hsdis solution to continue working on > > mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of > > > > this jep. > > > > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > > > > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has > > been left behind for a long time, and there are several requests to add new > > backends, which require a modernized build of hsdis. This is undfortunately > > not a high-priority project, and has been postponed several times already. > > :( > > Sorry I was under impression hsdis is not part of openjdk tree. > > Alan, could you please share with us the version of binutils you were using > in your test ? > > Regards, Vladimir I have updated PR with patch for hsdis, one thing to notice, LP64 is not defined for arm64 in Makefile - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Mon, 1 Feb 2021 14:06:32 GMT, Magnus Ihse Bursie wrote: >>> Hello, hsdis is a separate out-of-tree project and is not part of this jep. >> >> Unless there's something I'm missing it only requires a few lines of change >> to src/utils/hsdis/makefile (it already has support for macos x86_64) >> >>>support for looking for proper hsdis dylib library was added as part of this >>>jep. >> >> I'm a little confused. Are you planning on adding a new disassembler? > >> > Hello, hsdis is a separate out-of-tree project and is not part of this jep. >> >> Unless there's something I'm missing it only requires a few lines of change >> to src/utils/hsdis/makefile (it already has support for macos x86_64) > > I agree with Alan that it makes sense to add this trivial change as part of > this PR, if it allows the current hsdis solution to continue working on > mac/aarch64. > >> >> > support for looking for proper hsdis dylib library was added as part of >> > this jep. >> >> I'm a little confused. Are you planning on adding a new disassembler? > > @a74nh I think Vladimir is referring to > https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left > behind for a long time, and there are several requests to add new backends, > which require a modernized build of hsdis. This is undfortunately not a > high-priority project, and has been postponed several times already. :( > > > Hello, hsdis is a separate out-of-tree project and is not part of this > > > jep. > > > > > > Unless there's something I'm missing it only requires a few lines of change > > to src/utils/hsdis/makefile (it already has support for macos x86_64) > > I agree with Alan that it makes sense to add this trivial change as part of > this PR, if it allows the current hsdis solution to continue working on > mac/aarch64. > > > > support for looking for proper hsdis dylib library was added as part of > > > this jep. > > > > > > I'm a little confused. Are you planning on adding a new disassembler? > > @a74nh I think Vladimir is referring to #392. The hsdis "component" has been > left behind for a long time, and there are several requests to add new > backends, which require a modernized build of hsdis. This is undfortunately > not a high-priority project, and has been postponed several times already. :( Sorry I was under impression hsdis is not part of openjdk tree. Alan, could you please share with us the version of binutils you were using in your test ? Regards, Vladimir - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Mon, 1 Feb 2021 12:35:05 GMT, Alan Hayward wrote: > > Hello, hsdis is a separate out-of-tree project and is not part of this jep. > > Unless there's something I'm missing it only requires a few lines of change > to src/utils/hsdis/makefile (it already has support for macos x86_64) I agree with Alan that it makes sense to add this trivial change as part of this PR, if it allows the current hsdis solution to continue working on mac/aarch64. > > > support for looking for proper hsdis dylib library was added as part of > > this jep. > > I'm a little confused. Are you planning on adding a new disassembler? @a74nh I think Vladimir is referring to https://github.com/openjdk/jdk/pull/392. The hsdis "component" has been left behind for a long time, and there are several requests to add new backends, which require a modernized build of hsdis. This is undfortunately not a high-priority project, and has been postponed several times already. :( - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Mon, 1 Feb 2021 11:19:34 GMT, Vladimir Kempik wrote: > Hello, hsdis is a separate out-of-tree project and is not part of this jep. Unless there's something I'm missing it only requires a few lines of change to src/utils/hsdis/makefile (it already has support for macos x86_64) >support for looking for proper hsdis dylib library was added as part of this >jep. I'm a little confused. Are you planning on adding a new disassembler? - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Mon, 1 Feb 2021 09:31:31 GMT, Alan Hayward wrote: > You need add macos arm64 to hsdis. Having it working is fairly essential for > debugging. > > Inside src/utils/hsdis, After cloning binutils > > ``` > make; make demo; ./build/macosx-arm64/hsdis-demo > ``` > > Results in: > > ``` > Hello, world! > ...And now for something completely different: > > Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual > hsdis: bad native mach=architecture not set in Makefile!; please port hsdis > to this platform > hsdis output options: > ``` > > I fixed it by changing the makefile to force the build flags: > > ``` > ARCH=aarch64 > CFLAGS/aarch64+= -m64 > ``` > > Resulting in: > > ``` > Hello, world! > ...And now for something completely different: > > Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual > Decoding for CPU 'aarch64' > main: > 0x10012719c sub sp, sp, #0x60 > 0x1001271a0 stp x29, x30, [sp, #80] > ...etc > ``` > > Putting the library in the right place then made disassembly in java work for > me. Hello, hsdis is a separate out-of-tree project and is not part of this jep. support for looking for proper hsdis dylib library was added as part of this jep. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Wed, 27 Jan 2021 14:58:27 GMT, Vladimir Kempik wrote: >> Build changes per se now looks okay. However, I agree with Erik that unless >> this PR can wait for the JNF removal, at the very least the build docs needs >> to be updated to explain how to successfully build for this platform. (I can >> live with the configure command line hack, since it's temporary -- otherwise >> I'd have requested a new configure argument.) This can be done in this PR or >> a follow-up PR. > >> Build changes per se now looks okay. However, I agree with Erik that unless >> this PR can wait for the JNF removal, at the very least the build docs needs >> to be updated to explain how to successfully build for this platform. (I can >> live with the configure command line hack, since it's temporary -- otherwise >> I'd have requested a new configure argument.) This can be done in this PR or >> a follow-up PR. > > I believe it's better be done under separate PR/bugfix, so it can be > completely reverted once JNF removed. You need add macos arm64 to hsdis. Having it working is fairly essential for debugging. Inside src/utils/hsdis, After cloning binutils make; make demo; ./build/macosx-arm64/hsdis-demo Results in: Hello, world! ...And now for something completely different: Decoding from 0x1046e31a4 to 0x1046e3664...with decode_instructions_virtual hsdis: bad native mach=architecture not set in Makefile!; please port hsdis to this platform hsdis output options: I fixed it by changing the makefile to force the build flags: ARCH=aarch64 CFLAGS/aarch64+= -m64 Resulting in: Hello, world! ...And now for something completely different: Decoding from 0x10012719c to 0x10012765c...with decode_instructions_virtual Decoding for CPU 'aarch64' main: 0x10012719csub sp, sp, #0x60 0x1001271a0stp x29, x30, [sp, #80] ...etc Putting the library in the right place then made disassembly in java work for me. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie wrote: > Build changes per se now looks okay. However, I agree with Erik that unless > this PR can wait for the JNF removal, at the very least the build docs needs > to be updated to explain how to successfully build for this platform. (I can > live with the configure command line hack, since it's temporary -- otherwise > I'd have requested a new configure argument.) This can be done in this PR or > a follow-up PR. I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Tue, 26 Jan 2021 21:59:03 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks >> JDK-8253817, JDK-8253818) >> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with >> necessary adjustments (JDK-8253819) >> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), >> required on macOS/AArch64 platform. It's implemented with >> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a >> thread, so W^X mode change relates to the java thread state change (for java >> threads). In most cases, JVM executes in write-only mode, except when >> calling a generated stub like SafeFetch, which requires a temporary switch >> to execute-only mode. The same execute-only mode is enabled when a java >> thread executes in java or native states. This approach of managing W^X mode >> turned out to be simple and efficient enough. >> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) > > Anton Kozlov has updated the pull request incrementally with one additional > commit since the last revision: > > Redo buildsys fix Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR. - Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster wrote: >> @luhenry , could you please check this comment, I think SA-agent was MS's >> job here. > > The target is identified by the header file now: > https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41 > > Do you think there is any problem with this approach? @lewurm No, that's okay. I just wanted to know that this had not been lost. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v6]
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818) > * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary > adjustments (JDK-8253819) > * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), > required on macOS/AArch64 platform. It's implemented with > pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a > thread, so W^X mode change relates to the java thread state change (for java > threads). In most cases, JVM executes in write-only mode, except when calling > a generated stub like SafeFetch, which requires a temporary switch to > execute-only mode. The same execute-only mode is enabled when a java thread > executes in java or native states. This approach of managing W^X mode turned > out to be simple and efficient enough. > * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941) Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Redo buildsys fix - Changes: - all: https://git.openjdk.java.net/jdk/pull/2200/files - new: https://git.openjdk.java.net/jdk/pull/2200/files/b2b396fc..f1ef6240 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=04-05 Stats: 18 lines in 2 files changed: 8 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/2200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 PR: https://git.openjdk.java.net/jdk/pull/2200
