On Thu, 13 Mar 2025 07:39:20 GMT, Christoph Langer <clan...@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
