RFR: 8351842: Test issues on Windows with combination of --enable-linkable-runtime and --with-external-symbols-in-bundles=public [v2]

[Severin Gehwolf]

On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`.
>> 
>> The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named <binary-name>.pdb. The second set consists of stripped debug symbols file called <binary-name>.stripped.pdb which have less information but enough to present line numbers in hs-err files.
>> 
>> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored.
>> 
>> With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs.
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tests

Maybe, I misunderstood how this works... I'm not a Windows person.

> My take is that we should be able to both test and debug what we ship.

Agreed. What I don't understand why this inconsistency is being done to begin with? To appease testing maybe? Is that the idea?

> During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without _stripped_) from images, but in the runtime the hashes of the _stripped_ files are stored.

I'll add here that the implementation of JEP 493, does nothing special. It takes what's in the JMODs *at build time* when `jlink` is being run and uses that as the "source of truth" when it comes to hash sums. It sounds to me that when `jlink` runs during the build it only sees `*.stripped.pdb` files (renamed as `*.pdb`). If something is being done **after** the `jdk` image has been created (by `jlink`) and changes files (like copying full `*.pdb` files over the stripped ones that are actually in the JMODs) then this is the root cause of this bug. Rightfully so, since the `*.pdb` files in the JDK image no longer match the ones in the JMOD files. Is that the case? @RealCLanger Could you please run these commands for me and let me know the output? Sorry, I don't know the windows equivalents of these:


$ jmod extract --dir java.base-jmod-extract images\jmods\java.base.jmod
$ sha512sum java.base-jmod-extract\bin\keytool.exe.pdb
5df21e93cd24a03e491debd469001fc73950812de2d2b5d6df0272b55e9d206b56a4332a9f77e19e8755da12dc43f1c353575503b1f53d3d894794e19632964a java.base-jmod-extract\bin\keytool.exe.pdb
$ jimage extract --dir lib-modules-extract images\jdk\lib\modules
$ grep keytool.exe.pdb lib-modules-extract\jdk.jlink\jdk\tools\jlink\internal\runtimelink\fs_java.base_files
6|0|5df21e93cd24a03e491debd469001fc73950812de2d2b5d6df0272b55e9d206b56a4332a9f77e19e8755da12dc43f1c353575503b1f53d3d894794e19632964a|bin\keytool.exe.pdb
$ sha512sum images\jdk\bin\keytool.exe.pdb
<different-to-5df21e93cd24a03e491debd469001fc73950812de2d2b5d6df0272b55e9d206b56a4332a9f77e19e8755da12dc43f1c353575503b1f53d3d894794e19632964a>

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

PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2720746544