Hello Frederic,
I'm well aware of the problem you describe as I was involved in porting
it from the JDK 7 build system to the rewrite in JDK 8, and wasn't able
to figure out a good solution for it then, so if this can be solved, I'm
definitely interested. Is the "foo.dll" -> "foo.dll.pdb" actually
recognized as a naming convention by Windows tools, or are they just
reading the link recorded in the binary? Regardless of which, if we
aren't bound to the current naming convention for tool compatibility, I
think your suggested one seems as good as any. I would be interested to
hear from others with more experience developing and debugging on
Windows though.
/Erik
On 10/2/23 11:21, Frederic Thevenet wrote:
Hi,
I would like to submit the following proposal for discussion on this
list: changing the naming convention for debug symbol files on
Windows, in order to avoid collisions.
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).
While this is indeed a common convention on Windows - and the default
configuration in Visual Studio - this has the unfortunate side effect
of producing colliding paths in the event of an exe and a dll file
sharing the same target folder and file name, save for the extension.
In the case of OpenJDK, there are three occurrences (that I am aware
of) where this happens: "bin\java.exe" and "bin\java.dll" resolve to
the same "bin\java.pdb" for their symbols, as do
"jimage.exe/jimage.dll" and "jpackage.exe/jpackage.dll", meaning both
set of debug information cannot naturally coexist while strictly
adhering to the rule.
(NB: Builds for unix-like platforms are not affected by this, due to
a/ the fact that libraries and launchers are not located in the same
folder, b/ the radical for executables and libraries typically differ,
e.g. java / libjava)
Since it is generally admitted that the debug symbols for the
libraries contain are likely to be more useful that those for the
launchers, specific build logic has to be added in several places to
ensure those symbols are always prioritized [1][2].
This is nonetheless a sub-optimal situation, since:
- it leaves out entirely the debug info for java.exe, jpackage.exe
and jimage.exe
- It requires special case handling in the build logic to guaranty
consistency in what symbols are kept, which needs to be updated each
time a new occurrence is introduced.
- It is overall surprising to developers unaware of this situation
and likely to raise suspicion of a bug[3].
One way to avoid all the issues above, would be to adopt a naming
strategy for the pdb files that does not incur a risk of collision;
for instance by keeping the original extension in the final name, e.g.
"jvm.dll" -> "jvm.dll.pdb" instead of "jvm.pdb" (and
"jvm.dll.stripped.pdb" for stripped symbols if
"--with-external-symbols-in-bundles=public" is used, "jvm.dll.diz" for
"--with-native-debug-info=zipped").
According to my initial findings, the changes to accomplish this are
quite straight forward and easy to circumscribe to the Windows build [4].
Also, I have verified that the ".pdb" files with the new names are
recognized by the Windows debugger in the same way as the old one;
i.e. it requires no extra configuration steps to tell the debugger
where to find the right symbol files [5].
I'm looking forward to your feedback on this proposal.
Thanks,
[1]
https://github.com/openjdk/jdk/blob/a564d436c722f14041231158f21c4ad3a2f6a3a5/make/Images.gmk#L277
[2]
https://github.com/openjdk/jdk/blob/a564d436c722f14041231158f21c4ad3a2f6a3a5/make/CreateJmods.gmk#L84
[3] https://bugs.openjdk.org/browse/JDK-8263356
[4]
https://github.com/fthevenet/jdk/commit/877a3db829e4b3bba2bef05950e22de7ed89e3f8
[5] The naming used at the moment is the one commonly used on Windows
but the name of pdb file can be whatever; it is in fact stored within
the PE header of the artifact, which is how the debugger knows how to
match them. See
https://polystream.com/behind-the-curtain-understanding-the-magic-behind-loading-symbols-in-visual-studio/