RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public [v6]

[Erik Joelsson]

On Mon, 1 Dec 2025 09:31:58 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 two additional commits since the last revision:
> 
>  - Cleanup comment
>  - Fix pdb filtering for JMODs build

> OK, finally I have updated my PR to implement the suggestions of @erikj79. Now the exploded image during the build will only contain the full pdb files and in the actual JDK and JRE images, we'll have the stripped pdb files (as well as in the jmods), if the option is set. And this also propagates to bundles. The debug image/debug bundle will of course only have the full symbol files.

>From what I can tell, this is also removing the full debug symbols from the actual JDK/JRE images in all cases and all platforms, so they actually match the bundles. I think that's ok, but it needs to be clearly stated somewhere, at least in the bug, for future reference of when that happened.

make/CreateJmods.gmk line 72:

> 70:         DEST := $(LIBS_DIR_FILTERED), \
> 71:         FILES := $(FILES_LIBS), \
> 72:         NAME_MACRO := rename_stripped \

These trailing commas were deliberate and are part of the [Code Conventions for the Build System](https://openjdk.org/groups/build/doc/code-conventions.html) (17, though it's not very clearly stated).

make/Images.gmk line 313:

> 311:   $(call SetupCopyStrippedDebuginfo,JDK)
> 312:   $(call SetupCopyStrippedDebuginfo,JRE)
> 313: endif

I might be missing something, but why is this needed? Shouldn't the public pdbs already be part of the jmods in this case and so would get linked into the image by jlink?

make/Images.gmk line 322:

> 320:       $(eval DBGFILES := $(if $(filter true+public,$(call isTargetOs,windows)+$(SHIP_DEBUG_SYMBOLS)), \
> 321:         $(filter-out %.stripped.pdb,$(DBGFILES)),$(DBGFILES)) \
> 322:       ) \

I think I would use lower case for `DBGFILES` to signify a local variable and reduce risk of clashing with any other variable in the current context.

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

PR Review: https://git.openjdk.org/jdk/pull/24012#pullrequestreview-3525547958
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2577512768
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2578323956
PR Review Comment: https://git.openjdk.org/jdk/pull/24012#discussion_r2578344932