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

Inlining breaks LLDB expression evaluator #35487

Closed
vadimcn opened this issue Aug 8, 2016 · 3 comments
Closed

Inlining breaks LLDB expression evaluator #35487

vadimcn opened this issue Aug 8, 2016 · 3 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@vadimcn
Copy link
Contributor

vadimcn commented Aug 8, 2016

Compile this code with -Copt-level=0:

#[inline(never)]
fn zzz() {}

#[inline(always)]
fn inlined_fn() {
    let a = 1;
    zzz(); // #break
}

fn main() {
    inlined_fn();
}

In LLDB, set a breakpoint on line 8, then run the program.
After breaking, type print a'. Result:

error: use of undeclared identifier 'a'
error: 1 error parsing expression

Interestingly, the frame variable command shows the expected value: (int) a = 1.

Meta:
LLDB version: lldb-360.1.25 (OSX XCode 8)
Rustc version: rustc 1.10.0 (cfcb716 2016-07-03) x86_64-apple-darwin

@vadimcn vadimcn added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Aug 8, 2016
@vadimcn
Copy link
Contributor Author

vadimcn commented Aug 8, 2016

Note: this is very likely an LLDB bug, because an equivalent C++ code exhibits the same behavior.

__attribute__((noinline))
void zzz() {}

__attribute__((always_inline))
void inlined_fn() { 
    {
    int a = 1;
    zzz(); // #break
    }
}

int main() {
    inlined_fn();
    return 0;
}

The extra lexical scope in inlined_fn is important - without it, evaluation produces the correct result: (int) $0 = 1

GDB works correctly.

@michaelwoerister
Copy link
Member

That makes me sad :(

@Mark-Simulacrum
Copy link
Member

So if this is an LLDB bug, then it seems like there's no use in us tracking it. As such, I'm going to close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

No branches or pull requests

3 participants