On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet <ftheve...@openjdk.org> wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external", >> the resulting debug symbols are saved in files located in the same folder as >> the corresponding executable or library and named by swapping the extension >> ".exe" or ".dll" for a ".pdb" one (or "diz" if option >> "--with-native-debug-info=zipped" is used), which means that in the event of >> an exe and a dll file sharing the same target folder and file name (e.g. >> `bin\java.exe` and `bin\java.dll`), we have to choose whether symbols in >> `bin\java.pdb` will refer to the exe or the dll; we can't have both. >> >> This PR addresses this issue by adopting a different naming strategy for the >> resulting symbol files where we keep the full name of every file - including >> its `dll` or `exe` extension) and then add the appropriate `.pdb`, `.map` or >> `.diz` extension . >> >> For instance, `jvm.dll` symbols are no longer called `jvm.pdb` but instead >> `jvm.dll.pdb`. Similarly, it is now `jvm.dll.diz` when using zipped symbols, >> and "jvm.dll.stripped.pdb" for stripped symbols (i.e. when >> "--with-external-symbols-in-bundles=public" is used). >> >> The PR also removes the existing filtering for java.pdb, jimage.pdb and >> jpackage.pdb used to guaranty the dll symbols were bundled over the ones >> from the exe, since we no longer need that. > > Frederic Thevenet has updated the pull request incrementally with one > additional commit since the last revision: > > Added a test to verify that symbols are available > I finally opted to address the underlying issue by patching > RunTestsPrebuilt.gmk, rather than GHA; #16343. > > As for this PR, I see two possible ways forward; one is to remove the test > and integrate the change without it as part of the current PR, and add the > test back in a follow up once the RunTestsPrebuilt patch is integrated. The > other is to convert this PR to a draft, wait for the separate fix to be > integrated, and then rebase this PR on top of it and resume its review. > > I like the first one better; a few more steps but overall less fussy. I'm > also open to another solution. +1 Vote for first option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16039#issuecomment-1777750064
