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 some tests by building the JDK's master branch (e.g. *without* this patch) with `--with-external-symbols-in-bundles=public` and then renaming the generated `jvm.dll.pdb` to `jvm.dll.full.pdb`. I left `jvm.dll.stripped.pdb` unchanged. Then using [WinDbg](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/) to debug jshell, I could confirm that in fact WinDbg could *not* load symbols for `jvm.dll` neither from `jvm.dll.full.pdb` nor from `jvm.dll.stripped.dll`, It would resort to what it calls "exported symbols" for this module, which you can't use for doing much. Then I renamed `jvm.dll.full.pdb` back to `jvm.dll.pdb` and restarted the debugger and confirmed I could now set a breakpoint in the source file and have the debugger step in and highlight source lines properly, as expected. Finally I named `jvm.dll.stripped.pdb` as `jvm.dll.full.pdb` and reloaded everything; this time I could view the functions names in the jvm modules displayed properly in the debugger console when stepping, but could no longer follow its excecution from the source code view. Again this is expected since public symbols contain function names and entry point addresses but not source file and line number info. So it seems that contrary to what I suggested in my previous comment, it *is* important that the `.pdb` file from where the debugger is expected to load symbols from is the same name as was provided to the linker. Now the reason why I initially thought it didn't matter is because `WinDbg` automatically caches pdb files that it successfully loaded under `C:\ProgramData\dbg\sym` and reload them from there even if the original file no longer exist. So if you load the symbols once, then rename the file and start again, you may be misled into thinking that it successfully loaded the symbols from the renamed file while it in fact did so from its cache. Hope this helps, and sorry for the potential misleading info earlier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-2722436351
