[PATCH] D52444: [DWARF] Make llvm-dwarfdump display the .debug_loc.dwo section (fixes PR38991)

[Wolfgang Pieb via Phabricator via llvm-commits]

wolfgangp added inline comments.


================
Comment at: test/tools/llvm-dwarfdump/X86/debug_loc_dwo.ll:5-6
+
+; Make sure llvm-dwarfdump can display a location list in a split dwarf context
+; (i.e. in the .debug_loc.dwo section).
+;
----------------
dblaikie wrote:
> wolfgangp wrote:
> > dblaikie wrote:
> > > I think this is already tested - in, say, test/DebugInfo/X86/fission-ranges.ll
> > > 
> > > I think you can probably skip this test case - and just keep the other one that's testing the new functionality you're enabling?
> > There is a subtle difference between the fission-ranges.ll and this one. In fission-ranges, the object file contains both the non-split and the split sections, which is why it was passing even before this fix.
> > 
> > The new test case demonstrates that it works also when the .dwo sections have been separated out into a separate .dwo file, which was not working.
> > 
> > I can fold this case into fission-ranges if you prefer.
> Ah, I see.
> 
> Not sure it's worth test coverage though - if it can be dumped without any other sections (demonstrated by the other test), then the fact that it can be dumped with some but not other sections present seems like it's not an interesting/distinct case to test for?
True, the other test case covers the failing case as well. I'll remove it then.


================
Comment at: test/tools/llvm-dwarfdump/X86/debug_loc_dwo.s:15
+# end_of_list), which is what llvm generates as well. llvm-dwarfdump just dumps the
+# index without interpreting it any further.
+.byte 3          # DW_LLE_startx_length
----------------
dblaikie wrote:
> wolfgangp wrote:
> > dblaikie wrote:
> > > What further interpretation of the address index could it do?
> > > What further interpretation of the address index could it do?
> > 
> > Theoretically, if you're dumping an object file where the fission sections haven't been separated out yet, you could refer to the skeleton unit's .debug_addr section through the index and dump the actual addresses. Don't know if that would be a common use-case, though.
> Fair enough - doesn't seem to be relevant to this test case (since there's no debug_addr section in this file), so might be confusing in a comment here?
OK I'll get rid of it.


https://reviews.llvm.org/D52444