-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Fix debug line number info for macro expansions. #35238
Conversation
Failed tidy. |
return wrap(cast<MDNode>(unwrap<MetadataAsValue>(value)->getMetadata())); | ||
else | ||
return NULL; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing newline.
One thing that's interesting here and I didn't consider while looking into this myself, is having both |
433c59f
to
5fe1a78
Compare
☔ The latest upstream changes (presumably #35174) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks for the PR, @vadimcn! I'll have a look at it shortly. |
5fe1a78
to
659f420
Compare
rebased |
Travis says:
|
Hmm, this appears to be legit. Looks like LLVM screws up variable debug info for "inlined" scopes. @eddyb might be right about needing |
OK, I've looked this over and done some research. In principle this is a great idea. However, I'm a bit worried about doing something that is not really supported by LLVM. Here's some background: In DWARF, inlined function instances are represented by However, each
That would also mean that we can't step into code within a macro at all, right? You would always just step over it. That doesn't sound like an acceptable solution either. And at least in MSVC I seem to remember that I was able to step through code within macros. If we could somehow make it reliably work that macros look like inlined functions to the debugger, that would be great. I would consider it an acceptable trade-off then if one would not be able to see local variables defined outside a macro while stepping through code within it. |
I think this isn't necessarily a problem in itself. After all, recursive functions can be inlined.
I am pretty sure we wouldn't be able to see vars from outer scopes. But this is also the case in the current state of this PR.
This may be a limitation of DWARF vs PDB. I would argue that this would still be an improvement over the current situation, where you are taken inside a macro whether you want it or not. So, IMO, worth considering. |
You're right. Maybe it's no problem then that there is no separate subprogram DIE for the macro.
Yes, that's a problem that would need to be resolved before this PR can land.
I would argue that it's better that macros can be inconvenient than not being able to inspected them at all. I guess people's opinion on this will vary depending on how they are using macros. |
Update: I have a fix for the inner variables not showing up, however that works only partially (only for I also tried emitting dummy functions for macros. This un-breaks
I disagree. Most of the users don't need to debug macro innards, but they need to step over them quite regularly ( |
That would only be the case when you have a "top level" |
So, it seems pretty clear to me now that we have to emulate, on the LLVM IR level, what the LLVM inlining pass would do when it's inlining a function. What that is exactly, I don't know yet |
I'd say it's more like we are trying to reverse-engineer "what kind of a function would generate this code when inlined?" To clarify, what I've been talking about on IRC, consider this code: macro_rules! MACRO {
() => {
bbb();
let ccc = 1;
ddd();
}
}
fn function() {
aaa();
MACRO!();
eee();
} After expansion: fn function() {
aaa();
bbb();
let ccc = 1;
ddd();
eee();
} Right now we create two visibility scopes here: scope A for the whole |
Here's what a quick investigation turned up:
None of this is very surprising actually. To emulate this for macros, the pseudo |
659f420
to
aa1f77d
Compare
Per team discussion, implemented the C++ approach, i.e. stamp expanded code with the location of the expansion site. r? |
aa1f77d
to
702fbb7
Compare
☔ The latest upstream changes (presumably #35340) made this pull request unmergeable. Please resolve the merge conflicts. |
I'll take a look shortly. |
scopes[scope] = MirDebugScope { | ||
scope_metadata: fn_metadata, | ||
start_pos: loc.file.start_pos, | ||
end_pos: loc.file.end_pos, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be more correct to have the start and end pos of the function instead of the file containing it?
💔 Test failed - auto-linux-cross-opt |
@bors retry |
⌛ Testing commit 6a9db47 with merge 143ce0c... |
💔 Test failed - auto-linux-64-cross-freebsd |
@bors: retry On Tue, Aug 23, 2016 at 11:40 AM, bors notifications@github.com wrote:
|
⌛ Testing commit 6a9db47 with merge 47ebb6f... |
💔 Test failed - auto-linux-64-x-android-t |
☔ The latest upstream changes (presumably #35764) made this pull request unmergeable. Please resolve the merge conflicts. |
6a9db47
to
f0164b1
Compare
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines. In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
f0164b1
to
cf64611
Compare
@bors: r=michaelwoerister |
📌 Commit cf64611 has been approved by |
…woerister Fix debug line number info for macro expansions. Macro expansions result in code tagged with completely different debug locations than the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines. This change fixes the problem by tagging expanded code as "inlined" at the macro expansion site, which allows the debugger to sort it out. Note that only the outermost expansion is currently handled, stepping into a macro will still result in stepping craziness. r? @eddyb
⌛ Testing commit cf64611 with merge 540cdd6... |
…woerister Fix debug line number info for macro expansions. Macro expansions result in code tagged with completely different debug locations than the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines. This change fixes the problem by tagging expanded code as "inlined" at the macro expansion site, which allows the debugger to sort it out. Note that only the outermost expansion is currently handled, stepping into a macro will still result in stepping craziness. r? @eddyb
⛄ The build was interrupted to prioritize another pull request. |
Macro expansions result in code tagged with completely different debug locations than the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines.
This change fixes the problem by tagging expanded code as "inlined" at the macro expansion site, which allows the debugger to sort it out.
Note that only the outermost expansion is currently handled, stepping into a macro will still result in stepping craziness.
r? @eddyb