[LLVMdev] Inconsistent use of is_stmt flag in .debug_line

Bernard Ogden Bernard.Ogden at arm.com
Fri Apr 26 06:14:41 PDT 2013


Hello,

A recent series of commits, ending with r169304 and relating to PR13303, add is_stmt to line entries for functions. This appears to be to work around problems with gdb.

However, I observe is_stmt is not always applied to line entries for functions. This may only affect the arm backend. Compiling the same code with the aarch64 backend does not demonstrate this problem.

It seems that 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);

It's easy to change this code to apply is_stmt for every line table entry but I think that this is the wrong approach. The real question is, why do we have an inconsistency where some function prologues contain instructions that can be mapped to the source line where the function begins, while others do not?

Could anyone point me the right way? As I mentioned, the problem may lie in the arm backend.

Thanks in advance,

Bernie

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.





More information about the llvm-dev mailing list