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