<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 9, 2017 at 2:57 PM Paul Robinson via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">probinson added a comment.<br>
<br>
(Moving the why-do-we-need-the-unit discussion out of the inline comments.)<br>
<br>
I do have a goal of being able to handle a line table without a unit, when possible.  However, there are constraints, and many times you still end up needing a unit.  Sadly, the caller of the line-table parser doesn't know whether the unit will be needed.<br>
<br>
In fact, for dumping a .debug_line.dwo, the unit should *not* be needed.  A .dwo doesn't have any addresses in it, and won't be v2, so all it needs to know is the 32/64 format, which is in the line-table header.</blockquote><div><br>Hmm, so why do we pass in the pointer size to it at all? Guess that should be fixed.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  However, because of how libDebugInfo works, the string-section handles are in DWARFUnit.  So, for a v5 line-table header that uses any indirect string form, the parser still needs the DWARFUnit even though it doesn't need the .debug_info compile/type unit.  I tilted at that windmill several times, and the windmill won every time.<br></blockquote><div><br>Could you summarize any of the issues you hit trying to move the string section handles out of the DWARFUnit? I'd have thought they could readily go into (or already be present in) the DWARFContext?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we defer looking up the unit until the line-table parser needs to know it, then the parser will frequently end up doing the linear scan through the units until it finds the right one (O(N*N/2)). </blockquote><div><br>Oh, I was figuring precomputing the map, but deferring the specific lookup until needed. So I wouldn't expect to repeatedly do a linear scan.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It seemed less inefficient to scan all the units once and do a map lookup each time instead (O(N+NlogN)).  I am guessing it will be unusual for a line table *not* to need the unit, </blockquote><div><br>If the string table refactoring was done then it would be rarely needed, right?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">so the unconditional lookup seemed like the better choice.  And the parser doesn't know whether it should search the normal or .dwo CUs, so.... might as well just do it up front in the caller.<br>
<br>
This does not mean my prior work was wasted, because with v5 using forms in the line-table header, the FormParams had to be split out anyway.  But even with v5, if the header uses FORM_strx, or the line-number program wants to use the .debug_addr table, we still need the unit.  (And again, given how libDebugInfo works, even FORM_strp needs the DWARFUnit, even though it doesn't need anything from the actual compile unit.)<br>
<br>
As I mentioned elsewhere, for my next trick I will conjure up a standalone v5 line table, and parse it without the assistance of any units.  But it will have to use all inline strings, until I can come back around to tracking the string sections independently of the DWARFUnit.<br></blockquote><div><br>*nod* Seems like there's an opportunity to setup the design with that future in mind, is what I think I'm getting at?<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<a href="https://reviews.llvm.org/D39854" rel="noreferrer" target="_blank">https://reviews.llvm.org/D39854</a><br>
<br>
<br>
<br>
</blockquote></div></div>