On Wed, 12 Mar 2025 15:57:40 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 whith this special build configuration, we build two sets 
> of .pdb files for the binaries. The first set is the standard debug symbols 
> file named <binary-name>.pdb. The second set is a stripped debug symbols file 
> called <binary-name>.stripped.pdb which has less information but enought 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.

What happens with the local debugging experience in the exploded image if you 
configure with ` --with-external-symbols-in-bundles=public`? Then the full 
debug symbols are only present in the *.full.pdb files. Will the debugger tools 
on Windows know automatically how to resolve that, or will this configuration 
be inconvenient for local dev/debug usecases? As I remember it, the current 
scheme was chosen to put the "full" pdb files as *.pdb in the exploded image 
whenever possible.

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

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

Reply via email to