[LLVMbugs] [Bug 14566] New: Unnamed lexical_blocks interfere with gdb's handling of qualified names

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Dec 10 14:25:55 PST 2012


             Bug #: 14566
           Summary: Unnamed lexical_blocks interfere with gdb's handling
                    of qualified names
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, echristo at gmail.com,
                    llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified

Found in gdb.base/watchpoint.exp, reduced to:

int func() {
  int i = 3;
  return i;

break func
watch func::i 
>> No symbol "i" in specified context.

If you disable clang's functionality that emits a DW_TAG_lexical_block at the
function level like this:

--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -846,17 +846,17 @@ public:
     /// \brief Enter a new cleanup scope.
     explicit LexicalScope(CodeGenFunction &CGF, SourceRange Range)
       : RunCleanupsScope(CGF), Range(Range), PopDebugStack(true) {
-      if (CGDebugInfo *DI = CGF.getDebugInfo())
-        DI->EmitLexicalBlockStart(CGF.Builder, Range.getBegin());
+      //if (CGDebugInfo *DI = CGF.getDebugInfo())
+      //  DI->EmitLexicalBlockStart(CGF.Builder, Range.getBegin());

     /// \brief Exit this cleanup scope, emitting any accumulated
     /// cleanups.
     ~LexicalScope() {
-      if (PopDebugStack) {
-        CGDebugInfo *DI = CGF.getDebugInfo();
-        if (DI) DI->EmitLexicalBlockEnd(CGF.Builder, Range.getEnd());
-      }
+      //if (PopDebugStack) {
+      //  CGDebugInfo *DI = CGF.getDebugInfo();
+      //  if (DI) DI->EmitLexicalBlockEnd(CGF.Builder, Range.getEnd());
+      //}

     /// \brief Force the emission of cleanups now, instead of waiting

then gdb behaves appropriately. I'm not sure if other transparent/unnamed
lexical_blocks also confuse GCC, but this one does. Emitting a lexical_block at
the function level seems at least slightly questionable - it's not unreasonable
to let the function be the scope. Equally I suspect this is evidence of an
underlying issue with lexical_blocks in GDB that we probably can't workaround
while still providing block fidelity with lexical_blocks. Probably nice to get
a GDB fix there if that's the case.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list