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.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 > >>>
