native debug symbols support on Windows

[Langer, Christoph]

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.

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.joelsson at oracle.com>
> Sent: Mittwoch, 4. Dezember 2019 15:46
> To: Bob Vandette <bob.vandette at oracle.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; build-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev
> developers <hotspot-dev at 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.joelsson at 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
> >>>