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

[Christoph Langer]

On Mon, 20 Oct 2025 12:04:03 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8351842
>  - Merge branch 'master' into JDK-8351842
>  - Fix tests
>  - JDK-8351842

Hi all, 

I have reopened this PR because I'd like to come back to the proposed coding changes and like to argue again that it seems the best and clearest solution for the issue.

Since the discussion in the PR has grown quite long, let me summarize first: With configure option `--with-external-symbols-in-bundles=public` we build a JDK that contains a set of stripped pdb files (instead of none or full blown pdbs). These stripped pdb files will be packaged into the module binaries and and are then expected by jlink, e.g. known by their hashcodes. We still build full blown pdb files to create the debug symbols bundle from. As it is currently set up, the images folder that is used for testing contains full pdb files named like `library.pdb` and the stripped pdb files named `library.stripped.pdb`. So far, this was no issue but with option `--enable-linkable-runtime` jlink would link runtimes not from jmod files (that contain only the stripped pdb files) but from the image folder directly where we still have the full blown pdb files named `library.pdb`. And those pdb files obviously don't match with the hashsums stored in jlink.

With this proposed change, we would then have stripped pdb files as `library.pdb` and the full pdb files as `library.full.pdb`. I think this is consistent because that's what is actually delivered in the JDK bundle. The reservation against this approach was, though, that it could harm the developer experience because one could not debug directly from the test image any more and would need to first replace the stripped pdb files with the full pdb files.

The question is, how often this problem would really hit a developer. And if so, is it really so hard to restore the full pdb files? I would argue, that having the stripped pdb files in the image directory is more consistent with what we actually ship and hence we better test the actual product. Furthermore, to mitigate this, one could add another make target or some script. However, I think it is definitely better than hacking something into jlink as proposed in the alternative PR #24057. Maybe another solution could be that `--with-external-symbols-in-bundles=public` would become effective in debug builds but only in product builds?

@erikj79 @magicus would you reconsider this?

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

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