RFR: 8317510: Change Windows debug symbol files naming to avoid losing info when an executable and a library share the same name [v3]

[Frederic Thevenet]

On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet <fthevenet at 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

>From what I can tell, the test fails because of an unrelated issue with the "test-prebuilt" target used to run the test by GHA.

According to the logs for the failed test, path to the symbol folder "/d/a/jdk/jdk/bundles/symbols/jdk-22/fastdebug" is passed explicitly via the env variable `SYMBOLS_IMAGE_DIR`: 

make test-prebuilt TEST='test/hotspot/jtreg/:tier1_runtime' BOOT_JDK=/d/a/jdk/jdk/bootjdk/jdk JT_HOME=jtreg/installed JDK_IMAGE_DIR=/d/a/jdk/jdk/bundles/jdk/jdk-22/fastdebug SYMBOLS_IMAGE_DIR=/d/a/jdk/jdk/bundles/symbols/jdk-22/fastdebug TEST_IMAGE_DIR=/d/a/jdk/jdk/bundles/tests JTREG='JAVA_OPTIONS=-XX:-CreateCoredumpOnCrash;VERBOSE=fail,error,time;KEYWORDS=!headful'


But looking into the hs_err report, we see the path for the symbols folder is not considered by the symbol engine:

symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;D:\a\jdk\jdk\bundles\jdk\jdk-22\fastdebug\bin;C:\Windows\SYSTEM32;C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17763.4851_none_de72d1b65349cfc4;D:\a\jdk\jdk\bundles\jdk\jdk-22\fastdebug\bin\server


That would still imply that the pdb files were stripped from the jdk bundle that is uploaded by the build task, or they would be picked by the symbol engine from there. Right now, I don't know if this is indeed the case, and if so caused by the renaming of pdb files in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16039#issuecomment-1755688349