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

[Erik Joelsson]

On Wed, 22 Oct 2025 19:52:06 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 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?

First just for clarity, the current file names are `library.dll.pdb` and `library.dll.stripped.pdb`, just to avoid any confusion in the discussion.

I don't think there is any value in having `library.dll.full.pdb` present in `JDK_IMAGE_DIR`. Instead, I would like to propose that when `--with-external-symbols-in-bundles=public` is set,  we continue building them as `library.dll.pdb` and `library.dll.stripped.pdb` into the exploded image. That will preserve the ability to debug the exploded image. When creating jmods we continue to rename and include the `library.dll.stripped.pdb` files instead of the full pdb files. When creating the image in `JDK_IMAGE_DIR`, we only include the stripped variants from the jmods, named `library.dll.pdb`. The full files we copy manually into the `SYMBOLS_IMAGE_DIR` dir instead, also named `library.dll.pdb`.

The `SYMBOLS_IMAGE_DIR` was introduced quite some time ago, I think by me, and my intention was to long term try to move the symbol files there completely. I never got around to it, it's quite a disruptive change, but I wanted a better 1 to 1 correlation between the images and the bundles we ship. I'm not sure we are ready for that kind of change yet, but I think we can leverage the `SYMBOLS_IMAGE_DIR` for this particular configuration option.

In `RunTests.gmk` we are already looking for PDB files in `SYMBOLS_IMAGE_DIR` and adding any directories containing such files to, and exporting, `_NT_SYMBOL_PATH`. This helps debuggers and symbol lookup on Windows find the the PDB files when running tests through the makefiles. In local runs of `make test` this isn't currently being used, because we never put any PDBs in the `SYMBOLS_IMAGE_DIR`, but in our internal distributed testing (at Oracle), through `make test-prebuilt`, we provide the contents of the symbols bundle as `SYMBOLS_IMAGE_DIR` to get it picked up, without having to overlay the symbols bundle on top of the JDK bundle in our test setup, so we know this works.

With my proposal, full symbols should still be automatically available when running tests on the full JDK image through the makefiles. The only caveat here is if a file `library.dll.pdb` in the same directory as `library.dll` is picked up before anything in `_NT_SYMBOL_PATH`, this would need to be tested. If running tests using Jtreg directly, or debugging other scenarios, the developer would need to opt out of `--with-external-symbols-in-bundles=public` and I think in that case that would be reasonable. I'm mostly after making sure that testing through the makefiles continues to work out of the box.

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

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