On Wed, 30 Sep 2020 00:55:23 GMT, Ludovic Henry <luhe...@openjdk.org> wrote:
>> When bringing up Hotspot onto new platforms, it is not always possible to >> compile hsdis because gcc is not yet >> available. For example, for Windows-AArch64 and macOS-AArch64. >> For some such platforms, it is possible to use LLVM as an alternative >> backend as it also supports a disassembler >> feature. > > @navyxliu I've merged the sources into `src/utils/hsdis` and added support to > build it in the Makefile. This is an interesting suggestion. There is a similar attempt at replacing binutils with capstone in https://bugs.openjdk.java.net/browse/JDK-8188073, which unfortunately has not seen much progress due to lack of resources; I don't know if you are aware of that? There is also a (extremely low priority) effort to rewrite the hsdis makefile to be part of the normal build system, see e.g. https://bugs.openjdk.java.net/browse/JDK-8208495. Neither of these should be any blocker for your change, but I think it might be good if you know about them. I have couple of concerns with your patch. One is the method in which LLVM is selected instead of binutils; afaict this depends on having the `LLVM` variable set when executing the makefile. At the very least, this should be documented in the README. I don't think any more complicated configuration is really necessary at this point. With full integration with the build system, a more user-friendly way of selecting hsdis backend should be implemented, though. Second, and I don't know if this is an artifact of git/github/the new skara tooling, but if you renamed hsdis.c to hsdis.cpp, this relationship does not show up, not even in the generated webrevs. Instead they are considered a new + a deleted file. This makes it hard to see what code changes you have done in that file. And third; have you tested that your changes (both changing the main file from C to C++, and any code changes in it) does not break the old binutils functionality? Afaic there are no test suites for exercising hsdis :-( so manual ad-hoc testing is likely needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/392
