Re: native debug symbols support on Windows

[Erik Joelsson]

On 2019-12-04 07:09, Langer, Christoph wrote:
Hi,

thanks for your comments.

The reason why I want to have (at least basic) internal debugging information 
is to have helpful callstacks in hs_err files on crashes.

We go to rather great length to provide this in our testing. The bundles 
target creates a symbols bundle that can be overlayed on top of the main 
bundle. The RunTests.gmk makefile can be supplied with the variable 
SYMBOLS_IMAGE_DIR (which should point to where the symbols bundle is 
unzipped if it's separate to the main JDK image) and sets up 
_NT_SYMBOL_PATH when running tests.

/Erik


So, Bob, I don't think the executables can contain debug information, just the 
compiled .obj files. When it comes to linking, the linker either generates a 
pdb file or nothing. That's at least how I read the MSDN documentation (of 
linker options /debug [0] and /pdb [1]).

Maybe an idea to implement "internal" debug symbols for Windows would be to copy the pdb 
files to the release bundle as well. But actually, it's a strange interpretation of 
"internal" in that case...

Thanks
Christoph

[0] 
https://docs.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info?view=vs-2019
[1] 
https://docs.microsoft.com/en-us/cpp/build/reference/pdb-use-program-database?view=vs-2019

-----Original Message-----
From: Erik Joelsson <erik.joels...@oracle.com>
Sent: Mittwoch, 4. Dezember 2019 15:46
To: Bob Vandette <bob.vande...@oracle.com>
Cc: Langer, Christoph <christoph.lan...@sap.com>; build-
d...@openjdk.java.net; core-libs-dev@openjdk.java.net; hotspot-dev
developers <hotspot-...@openjdk.java.net>
Subject: Re: native debug symbols support on Windows

Hello,

On 2019-12-04 06:26, Bob Vandette wrote:
There seems to be an option that will include debug information in
generated .obj files.  Assuming this option is supported in the
versions of Visual Studio we use, it could be used to implement “internal”
native debug symbols.
/Z7
We already use this when compiling, but we still link to external pdb
files. I was not aware of being able to link with the symbol information
internal.

While this seems like it could be implemented, my question is, does
anyone need it? The internal symbols on Linux was something the Linux
distros wanted as they like to move it out in a uniform manner later. I
can't really see a need for this on Windows, but I certainly wouldn't
object if someone else do and wants to implement the support in the
OpenJDK build.

/Erik

The /Z7 option produces object files that also contain full symbolic
debugging information for use with the debugger. These object files and the
built executable can be substantially larger than files that have no debugging
information. The symbolic debugging information includes the names and
types of variables, as well as functions and line numbers. No PDB file is
produced.
Bob.


On Dec 4, 2019, at 9:11 AM, Erik Joelsson <erik.joels...@oracle.com>
wrote:
Correct, with the Microsoft toolchain there is no support for internal. I
don't know what happens to the build if you try to configure it that way. Feel
free to come up with a reasonable behavior.
/Erik

On 2019-12-04 00:06, Langer, Christoph wrote:
Hi,

I'm currently looking into native debug symbols support for Windows.

The OpenJDK build system supports these two configure flags --with-
native-debug-symbols=<internal|external> (among a few other options
which I don't want to discuss here).
So, the name implies that for "internal", debug symbols should be
contained in the binaries. And "external" should create separate files that
contain the debug symbols. However, to my knowledge, Windows would
always make use of external symbol files, named *.pdb. And there is no way
to have the debug symbols included in the binaries. Is that correct or am I
wrong in this assumption?
If it's true, I guess --with-native-debug-symbols=internal would not
make sense on Windows and should rather be rejected by configure.
Otherwise, if we were to support --with-native-debug-symbols=internal, the
build is broken for target "test-image" when it comes to building/copying the
gtest image.
I'd like to fix either the one way or the other. What do people think?

Thanks for your help
Christoph