<div dir="ltr">This discussion originally started on a code review thread, but I figured I would continue it here since the patch has landed and I want to do more work as a followup.<div><br></div><div>So LLDB's LineTable data structures have the notion of a "terminal entry".  As I understand it, LineTables are structured as a sequence of "entries".  An entry consists of:</div><div><br></div><div>Start Line</div><div>End Line</div><div>Start Address</div><div>Byte Length</div><div>Is Terminal Entry</div><div><br></div><div>and this represents some piece of source code.  If you were to examine all line entries in the debug info, you would find that not all address ranges are covered.  For example, line 10 might correspond to address 0x12345 - 0x12347, and line 11 might correspond to address 0x12360.  So address 0x12348 - 0x12359 do not map to anything.  Probably they are not even code, but just space between functions, or other random data in the .text section of a binary that isn't code.</div><div><br></div><div>The problem is, building a line table requires the person parsing the debug info to specify where the terminal entries are.  Why?  Isn't it trivial to calculate this automatically?  Say you insert a bunch of line entries, now they're all sorted by address into some array of LineEntry structures.  It seems to me like n is a terminal entry if </div><div><br></div><div>(entries[n].address + entries[n].length) < entries[n+1].address</div><div><br></div><div>is true.  Why do we need to store a separate flag for it?</div><div><br></div><div>Is there ever a case where the above condition is true but it is not the end of a sequence?  Or where the above condition is false but it is the end of a sequence?</div></div>