[LLVMbugs] [Bug 15962] New: Inconsistent setting of is_stmt in .debug_line

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15962

            Bug ID: 15962
           Summary: Inconsistent setting of is_stmt in .debug_line
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: bogden at arm.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

is_stmt is not always applied to line entries for functions. I've only observed
this behaviour with the ARM backend, hence raising against Backend: ARM.

The attached source file produces the attached object when built like this:
clang -target arm step-through.c -integrated-as -g -O0 -c -mcpu=arm7tdmi
-mfloat-abi=soft

Examination of .debug_line shows that lines 5 and 21 do not have is_stmt set.
These are both lines where a function begins. Lines 1 and 14 _do_ have is_stmt
set, and these are also lines where a function begins. With the x86 and aarch64
backends, all lines have is_stmt.

I suppose this is technically correct DWARF but it is not very helpful to have
different behaviour when stepping through functions. It seems as though commit
169304 (relating to PR13303) was intended to apply is_stmt to all line table
entries.

I've done a little analysis, for what it's worth:

DwarfDebug::beginFunction always generates a line table entry with is_stmt for
each function. Later, in DwarfDebug::beginInstruction, we create more line
table entries. If we have an instruction in a function which:

1) Is associated with the line number of the beginning of the function
2) Comes before the end of the prologue

then we overwrite the earlier line table entry with a similar entry which lacks
the is_stmt flag. The relevant code is:

unsigned Flags = 0;
PrevInstLoc = DL;
if (DL == PrologEndLoc) {
  Flags |= DWARF2_FLAG_PROLOGUE_END;
  PrologEndLoc = DebugLoc();
}
if (PrologEndLoc.isUnknown())
  Flags |= DWARF2_FLAG_IS_STMT;

  if (!DL.isUnknown()) {
    const MDNode *Scope = DL.getScope(Asm->MF->getFunction()->getContext());
    recordSourceLine(DL.getLine(), DL.getCol(), Scope, Flags);

We could insert a hack here to resolve the inconsistency, but I think the right
thing to do is dispose of the inconsistency where some function prologues
contain instructions that can be mapped to the source line where the function
begins, while others do not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130510/0e140c59/attachment.html>