RFR: 8317510: Change Windows debug symbol files naming to avoid losing info when an executable and a library share the same name [v3]
Magnus Ihse Bursie
ihse at openjdk.org
Tue Oct 10 20:12:10 UTC 2023
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
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
More information about the build-dev
mailing list