RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis [v2]

Magnus Ihse Bursie ihse at openjdk.org
Wed May 15 13:35:05 UTC 2024


On Thu, 9 May 2024 07:50:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 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 two commits:
> 
>  - Add check for compiler in configure
>  - 8330988: Implementation of 8288293: Windows/gcc Port for hsdis

Hi Julian, sorry for not getting back to you.

The problem from my PoV is that this is a very large and intrusive patch in the build of the actual product, for a claimed problem in the tangential hsdis library. I have not understood a pressing business need to get a Windows/gcc port for hsdis, which means I can't really prioritize trying to understand this patch.

As you know, the build system does not currently really separate between "the OS is Windows" and "the toolchain is Microsoft". I understand that you want to fix that, and in theory I support it. However, you must also realize that making a complete fix of this requires a lot of work, for something that there is no clearly defined need. (After all, cl.exe works fine to create the build, has no apparent issues, and is as far as an "official" compiler for Windows as you can get.) That makes it fall squarely in the WIBNIs bucked ("wouldn't it be nice if...").

If you can fix just the hsdis build without changing anything outside the hsdis Makefiles, that would be a different story. Such a change would be limited in scope, easy to say it will not affect the product proper, and be easier to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2112546029


More information about the client-libs-dev mailing list