Oh well, this sentence in [0] says it all. "It is not possible to create an .exe or .dll that contains debug information. Debug information is always placed in a .obj or .pdb file.”
I guess you need to copy pdb files if you runtime debug information. Bob. > On Dec 4, 2019, at 10:09 AM, Langer, Christoph <christoph.lan...@sap.com> > 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. > > 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 >>>>>
