In D144008#4403456, @dzhidzhoev wrote:

In D144008#4403052, @ykhatav wrote:

In D144008#4401633, @dzhidzhoev wrote:

@akhuang @rnk @ykhatav could you please take a look at CodeViewReader.cpp change? Frankly, I am new to that format.

Thanks for taking care of this. Could you add a CodeView-specific test to make sure that the changes work as expected?

It seems that llvm/test/DebugInfo/COFF/global_visibility.ll test ensures that local/static local/global variables are handled properly. DISubprogram's retainedNodes references a few static local variables, and we check that these variables are present within CodeView dump. Is there a corner case I probably miss?

In D144008#4401633, @dzhidzhoev wrote:

@akhuang @rnk @ykhatav could you please take a look at CodeViewReader.cpp change? Frankly, I am new to that format.

I will open a design discussion to discuss what an appropriate flag will be to control this behavior.

In D144337#4194463, @dblaikie wrote:

If you consider the attached test case (llvm/test/DebugInfo/X86/contiguous-lexical-block.ll) you can see that the lexical block is fragmented into ranges due to the presence of an instruction having line number 0. This I believe is a bug and If the same test case is run on windows, Visual Studio' can't reliably print variable "i" because CodeView does not provide a mechanism for describing a lexical block with more than one address ranges. In order to prevent the line 0 instructions from breaking up a lexical block, in this patch, we fold the line zero machine instructions into the range.

Sure, I'm on-board there. I'll take your word for it that CV can't represent discontiguous scopes and making scopes contiguous is the better tradeoff than omitting them entirely.

I don't have a test case that demonstrates whether using or not using UnknownLocations could lead to a bug. It is an internal flag and is suitable for controlling whether or not line zero instructions are represented in the debug information and so, in my opinion, can be used to control the scope tree as well.. Do you have any other flags in mind that can be used instead of "UnknownLocations"?

I don't understand this bit - there can be zero locations for other reasons, apart from UnknownLocations - you could just check for the zero locations, without needing to check UnknownLocations too, right?

But maybe you're using UnknownLocations as a proxy for CV/MSVC debug info emission? That seems unfortunate/not suitable, and this behavior should be gated on/more directly test for CV output, I think?

No, my intent was not to use UnknownLocations as a proxy for CV, but I think it is safe not to fold line 0 instructions into a scope range when UnknownLocations is enabled. AFAIK, when UnknownLocations is enabled line 0 entries are emitted in the debug information. In my opinion, Folding these instructions when the switch is enabled could break stuff.

@hans maybe you've got thoughts on this stuff

In D144337#4190626, @dblaikie wrote:

In D144337#4185295, @ykhatav wrote:

In D144337#4183551, @dblaikie wrote:

Could you describe why this relates to/depends on the "UnknownLocations" flag? I'm not following from the description - we could still describe these locations as being at line zero, while including them in lexical scopes to avoid fragmented ranges, I think?

The reason why we want to check for “UnknownLocations” flag is that this flag is used to check if we want to add line 0 entries in the line table (in DwarfDebug.cpp) and thereby controlling whether or not line zero instructions are represented in the debug information. If we don’t check for this flag and skip the line 0 entries while extracting lexical scopes there will be a mismatch in the line table entries and lexical scopes.

Sorry, still not quite following. Could you walk me through an example of the bug you're trying to address with this patch? And an example of the bug you're trying to avoid introducing/that causes you to need this extra UnknownLocations checking?

Move UnknownLocations declaration to LexicalScopes.h

In D144337#4183551, @dblaikie wrote:

Could you describe why this relates to/depends on the "UnknownLocations" flag? I'm not following from the description - we could still describe these locations as being at line zero, while including them in lexical scopes to avoid fragmented ranges, I think?

The reason why we want to check for “UnknownLocations” flag is that this flag is used to check if we want to add line 0 entries in the line table (in DwarfDebug.cpp) and thereby controlling whether or not line zero instructions are represented in the debug information. If we don’t check for this flag and skip the line 0 entries while extracting lexical scopes there will be a mismatch in the line table entries and lexical scopes.

Change UnknownLocations to use boolorDefault

In D144337#4172962, @dblaikie wrote:

Does this need a flag? The patch describes doing this for CodeView? Could/should it be done unconditionally for CV?

When UnknownLocations is left at default, the line table includes line 0 entries, and the lexical scopes utilize them while computing the ranges. However, if the unknown locations are disabled, the line table already ignores line 0 entries. This patch modifies the lexical scope behavior to ignore line 0 entries when UnknownLocations is not enabled. If this change is applied unconditionally, the line table entries and lexical scope will not match, causing inconsistencies
Although the DWARF format has the ability to describe the split address ranges, it is possible that the lexical blocks with split address ranges can result in buggy behavior on Linux as well.

In D144337#4167827, @probinson wrote:

It seems strange to define the enum in a header for a module that uses it only once, and externalize it in a module that uses it several times.

I'd always thought this DefaultOnOff business should be generalized... Hmm I see boolOrDefault in CommandLine.h. Maybe we could convert UnknownLocations to use that, remove static from the definition, and then LexicalScopes.cpp can reference it as an extern.
I agree with you that UnknownLocations may be better defined with boolorDefault instead of DefaultOnOff. I can change that.

However, the reason I moved the definition of UnknownLocations to LexicalScopes.cpp was to avoid a link-time error. Defining UnknownLocations as extern in LexicalScopes.cpp gives a link-time error despite removing the "static" keyword from its definition in DwarfDebug.cpp. I see that the two object files are in different directories and while building the LexicalScopes.cpp file it is unable to find the definition of UnknownLocations. I am aware that it may not be the optimal approach so I would appreciate any feedback or consider alternative methods.

(Converting the rest of the DwarfDebug.cpp options from DefaultOnOff to boolOrDefault should not be part of your task. But maybe add a FIXME on the enum definition.)

ping

Fix metadata numbering

Nit:test-fix

Removed the attribute

Commit id: 70fdbf35de1c37a22a5321ed7d7d2c190d788549

Modified SourceLevelDebugging.rst to include information about memory location exp.

Updated my local branch with the latest changes

Worked on review comments

Updated the test to include the proper string functions

Added StringLocationExp to the new apis