On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet <[email protected]>
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
