native debug symbols support on Windows

Bob Vandette bob.vandette at
Wed Dec 4 15:21:35 UTC 2019

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.


> On Dec 4, 2019, at 10:09 AM, Langer, Christoph <christoph.langer at> 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]
> [1]
>> -----Original Message-----
>> From: Erik Joelsson <erik.joelsson at>
>> Sent: Mittwoch, 4. Dezember 2019 15:46
>> To: Bob Vandette <bob.vandette at>
>> Cc: Langer, Christoph <christoph.langer at>; build-
>> dev at; core-libs-dev at; hotspot-dev
>> developers <hotspot-dev at>
>> 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>
>> 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

More information about the core-libs-dev mailing list