<div dir="ltr">Does DWARF not store this information?  Because it seems like it could be efficiently stored in an interval tree, the question is just whether it is efficient to convert what DWARF stores into that format.<div><br></div><div>PDB returns line entries in the format I described, with a start address and a byte length, so to determine whether something is a terminal entry I have to add them to some kind of data structure that collapses ranges and then manually scan through for breaks in the continuity of the range.</div><div><br></div><div>Is there some way we can make this more generic so that it's efficient for both DWARF and PDB?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 7, 2016 at 3:13 PM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 7, 2016, at 3:07 PM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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:<br>
><br>
> Start Line<br>
> End Line<br>
> Start Address<br>
> Byte Length<br>
> Is Terminal Entry<br>
<br>
Not quite correct. There is no end line and there is no byte length. To efficiently store line entries that can be efficiently searched, we need to not have a length and not have an end line.<br>
<br>
> 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.<br>
><br>
> 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<br>
><br>
> (entries[n].address + entries[n].length) < entries[n+1].address<br>
><br>
> is true.  Why do we need to store a separate flag for it?<br>
<br>
Because there is no size in each LineEntry. We rely on the next line entry always terminating the previous one. So one marked with "i am a terminal entry" is required to finish off the previous one.<br>
<br>
> 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?<br>
<br>
Not sure these questions apply after what I said above.</blockquote></div>