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

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

Reply via email to