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 The code itself looks good. We just need to figure out why it is breaking on GHA. Something looks definitely fishy in our `get-bundles` action in GHA. It seems that the symbol path is not correctly exported to `test.yml`. It has this "how can this ever has worked???" look. I'll dig more into it... Edit: Nah, it was just me mixing up `steps.path-name.outputs.symbols` from get-bundles/action.yml with `steps.bundles.outputs.symbols-path` in test.yml. The former should was correct not to be `...outputs.symbols-path`, as I thought for a while. Obviously. Or not... Debugging GHA is a royal pain. It seems reasonable that the pdb file is generated correctly by the build: Copying images/symbols/bin/server/jvm.dll.pdb The symbols bundle seem to be correctly uploaded after the build. Uploaded D:\a\jdk\jdk\bundles\symbols-windows-x64.tar.gz (100.0%) bytes 41943040:44545171 The bundle seems to be properly downloaded and unzipped by the test script: Unpacking symbols bundle... The symbols dir sent to RunTest looks sane, but I can't say if it is really is correct: SYMBOLS_IMAGE_DIR=/d/a/jdk/jdk/bundles/symbols/jdk-22/fastdebug To verify this, you could add a patch like this: --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -148,6 +148,10 @@ jobs: echo "value=$PATH" >> $GITHUB_OUTPUT fi + - name: 'Check symbols' + run: > + ls -R ${{ steps.bundles.outputs.symbols-path }} + - name: 'Run tests' id: run-tests run: > You could also instrument RunTest.gmk to show if `_NT_SYMBOL_PATH` is actually set properly. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16039#pullrequestreview-1668753301 PR Comment: https://git.openjdk.org/jdk/pull/16039#issuecomment-1756078917 PR Comment: https://git.openjdk.org/jdk/pull/16039#issuecomment-1756108764 PR Comment: https://git.openjdk.org/jdk/pull/16039#issuecomment-1756109803