Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CodeView] Range-based for loop variables are not available when debugging #34872

Closed
llvmbot opened this issue Dec 5, 2017 · 3 comments
Closed
Labels
bugzilla Issues migrated from bugzilla debuginfo duplicate Resolved as duplicate

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Dec 5, 2017

Bugzilla Link 35524
Resolution DUPLICATE
Resolved on Dec 20, 2017 15:02
Version trunk
OS Windows NT
Blocks #28528
Reporter LLVM Bugzilla Contributor
CC @amccarth-google,@dpxf,@zmodem,@pogo59,@rnk

Extended Description

I encountered in yaml2coff.cpp. In the function layoutCOFF, there is a loop that begins like this.

// Assign each section data address consecutively.
for (COFFYAML::Section &S : CP.Obj.Sections) {

If you put a breakpoint in this loop and hover over S, or add a watch for it, it displays as "Variable is optimized away and not available."

This is at O0, so we really need this.

I haven't tried to make a minimal repro yet, but hopefully it's straightforward to do. This should be easy enough for anyone to repro though.

@pogo59
Copy link
Collaborator

pogo59 commented Dec 5, 2017

It looks like we generate DWARF for range-for variables, so this is
specific to CodeView. (You probably knew that, but I needed to check.)
Here's my teeny test case. If CodeView does the right thing with this,
and it takes a more complicated case to trigger the problem, it'll be
worth knowing whether we get it right for DWARF as well.

#include
int foo(std::vector v) {
int i = 0;
for (auto w : v) ++i;
return i;
}

I see a variable entry for 'w', with a stack location and the right type.
Oddly it's wrapped inside two lexical blocks, which seems excessive; I'd
have expected one.

@rnk
Copy link
Collaborator

rnk commented Dec 20, 2017

I tested some trivial range based for loops with integers, and nothing went wrong. It must be something else from the larger yaml2obj test case.

@rnk
Copy link
Collaborator

rnk commented Dec 20, 2017

I think the trouble is that there are really two range-based for loops and two variables named 'S'. Here's what I see in windbg:

0:000> dv
CP = 0x00000078c738f458 CurrentSectionDataOffset = 0xb7c __range = 0x000002674e329020 { size=73 }
__begin = {...}
__end = {...}
S = 0x00000267`4e35b380 # Valid S
__range =
__begin =
__end =
S = # Probably for the next loop
SymbolTableStart = 0x7ff7
NumberOfSymbols = 0x88e3e8ce
i =
e =
NumberOfAuxSymbols =

I'd dupe this against "we should implement S_BLOCK32 scopes".

*** This bug has been marked as a duplicate of bug llvm/llvm-bugzilla-archive#28458 ***

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla debuginfo duplicate Resolved as duplicate
Projects
None yet
Development

No branches or pull requests

3 participants