[PATCH] D33155: [DWARFv5] Support FORM_strp in the line table header

[David Blaikie via Phabricator via llvm-commits]

dblaikie added inline comments.


================
Comment at: lib/DebugInfo/DWARF/DWARFContext.cpp:193-196
+    DWARFUnit *U = nullptr;
+    if (!CUs.empty())
+      U = &**CUs.begin();
+    while (LineTable.Prologue.parse(lineData, &stmtOffset, U)) {
----------------
probinson wrote:
> dblaikie wrote:
> > Guessing this probably isn't right for DWP files? Or potentially for a DWO containing multiple CUs that might have different CU properties that are relevant to the line table?
> > 
> > Though that's perhaps an interesting question - since a DWO line table is just for type units, the CU won't have a reference to any line.dwo section, and multiple DWO TUs might refer to the same line table, I think? (I think LLVM produces only one, but I forget - it's been awhile since I implemented taht) so you'd want to pick one of the DWO TUs that references this line table to use here?
> There are no CU properties relevant to a DWO v5 line table.  The only reason we need a CU is because it is a convenient way to relay handles on the other sections that a v5 line table header might need (.debug_str etc).  So it doesn't matter whether the CU is related to the line table.
> 
> It's quite easy to argue that, therefore, we shouldn't pass a CU down at all, but something else that provides the same information.  I thought about that for a while, and decided that if we do go that route then probably it should be done as a separate commit, because all the existing APIs are expecting a CU.
> What do you think?
Ah, right - well, given the point was to make debug_line standalone, easier to preserve while stripping other things (if I recall/understand correctly) that seems like a good goal. It should be possible to dump a file that doesn't contain a debug_info section/any CUs and only line tables/debug_str/etc.

As for ordering - I'm not too fussed either way. I'd probably/ideally have staged the work to separate the needed properties out of the CU abstractions first, but since we're here I can't see any reason to make that a necessity for this work.


https://reviews.llvm.org/D33155