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

[Erik Joelsson]

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

I did a little bit of an experiment. When we link today, we supply this argument to define the main/full pdb file:

"-pdb:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).pdb" 

And in the case of `--with-external-symbols-in-bundles=public`, we also add this:

"-pdbstripped:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).stripped.pdb"


Just checking the contents of the resulting dll using `strings`, we can see that a reference to the pdb file is stored:

$ strings build/windows-x64/images/jdk/bin/verify.dll | grep pdb
verify.dll.pdb


This reference is the same wether I configure with `--with-external-symbols-in-bundles=public` or not, as in, strings does not find any `verify.dll.stripped.pdb` reference. Now with this patch, we instead supply:

"-pdb:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).full.pdb" 
"-pdbstripped:$$($1_SYMBOLS_DIR)/$$($1_BASENAME).pdb"

And then the stored reference becomes:

$ strings build/windows-x64-public-patch/images/jdk/bin/verify.dll | grep pdb
verify.dll.full.pdb


This is of course just an indication of what the Microsoft linker does and how the tools will interpret these libraries and executables. I haven't actually tested all the scenarios with debugging tools or generating hserr files. I do think it's enough to warrant a proper investigation before we change the `-pdb` flag to point to a filename other than `$$($1_BASENAME).pdb` though, as that could potentially have consequences for loading any kind of symbols in the final binaries.

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

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