http://llvm.org/bugs/show_bug.cgi?id=15405
David Blaikie <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #12 from David Blaikie <[email protected]> --- (In reply to comment #11) > I have not been able to find the time to run this on the gdb test suite. > > However, Dave's fix led me to realise that debug information was > deliberately being suppressed because it would be unnecessary: in this case > the debug information for the call instruction in question is guaranteed to > be the same as for the preceding instruction. > > It seems then that it would be better for me to adapt my tool on top of > CLANG to deal with this scenario rather than fixing the issue (which appears > to be a design decision, not a bug) in CLANG. > > If you agree then please go ahead and close the bug. > > Thanks for your help! > > Ally Coming back to this, I'm not sure I agree that this is the right thing for clang to do - the code in question breaks inlining which doesn't walk backwards from the call instruction looking for the last IR instruction to include a DebugLoc. Inlining just uses the debugloc of the call instruction - if it has none, but the calling function does, and the caller does have debug info, just no debugloc on this specific call instruction, bad things happen... the debugloc doesn't get wired up appropriately. I'm looking at fixing this one way or another - either removing these hacks (they might not be relevant anymore anyway - the DebugLoc encoding is now fairly efficient/low-cost, I believe, perhaps it wasn't when this hack was added?) or figuring out where to re-enable location information once we're passed the unconditional jump that these hacks were intended to skip debugloc for (but before we emit any more function calls/user-implied code) -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
