On Wed, 13 Oct 2021 00:32:03 GMT, Jorn Vernee <jver...@openjdk.org> wrote:

>> This patch expands the newly added system for hsdis backends to include LLVM.
>> 
>> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, 
>> as published in the never integrated PR 
>> https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out 
>> the binutils-based part of it.)
>> 
>> Unfortunately I have not been able to make this work properly on Windows. 
>> With some additional flags I made it compile without complaints, but it 
>> caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I 
>> tried to load the library. This is somewhat ironic, since the initial 
>> implementation was created by Ludovic for the very purpose of using it on 
>> Windows.
>> 
>> The lack of Windows support in this patch does not mean it is impossible to 
>> get it to work, just that I need to co-operate with someone who has more 
>> experience of compiling LLVM on Windows, and/or are more eager to get this 
>> combination to work.
>
>> but it caused hotspot to segfault in LoadLibrary (!) in os::dll_load when I 
>> tried to load the library.
> 
> I tried compiling the binutils-based hsdis earlier as well, but on WSL 
> instead of cygwin (using the `mingw-w64` package), and ran into the same 
> issue. It kept segfaulting when loading the library.
> 
> My guess was that it is a problem caused by mixing libraries that are 
> compiled with different toolchains, as the JDK itself is compiled with MSVC.
> 
> AFAIK binutils can only be built with mingw (based on my earlier 
> experiments), but LLVM can be built with MSVC as well, so maybe the regular 
> MSVC toolchain could be used to build the llvm-based hsdis.

@JornVernee It is likely that the LLVM-based backend can be build by MSVC, yes. 
I did not explore that further in this patch. I suggest that the way forward is 
to get this patch into mainline, and then experiment with how to get Windows 
support working properly. (The main problem with the MSVS approach is that the 
LLVM libraries, as returned by llvm-config, is in gcc format 
(`-lLLFoobarnicator`) which we can't send to CL. (It seems Ludovic tried to 
work around this by transforming the command line in his original PR.)

-------------

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

Reply via email to