[PATCH] D73086: [DWARF5] Added support for debug_macro section parsing and dumping in llvm-dwarfdump.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D73086#1885337 <https://reviews.llvm.org/D73086#1885337>, @SouraVX wrote:

> @dblaikie, I tried parsing multiple CU's contribution's[1 CU is fine] in a single DWARFDebugMacro object. It's not working out correctly, since every unit's contribution has it's own *header* apart from list of macros which can be easily parsed and dumped through a container. Even dumping is not straightforward, if all contributions are in a single object.
>  I'll try again,.
>  BTW are their down sights of the approach I followed. One step at a time take CU parse/dump and continue till offset is valid, since this is also used in location list parsing and dumping i.e Each contribution getting it's own object and header resides separately in other place.


Yes, the particular downside I was trying to avoid is that the common code ended up being used in two very different ways - especially the early return in DWARFDebugMacro.cpp:96 - that the debug_macinfo code uses that loop to read all the contributions, but the debug_macro uses the same code to stop after the first list based on version number is pretty subtle/divergent in ways that would be best avoided to make the code consistent and thus easier to understand and maintain.

The header information would need to be kept on a per-MacroList basis (the MacroList is currently just the raw vector - that won't be sufficient - probably a refactoring patch or two to make MacroList an actual structure, so it can have the header member(s) added to it for debug_macro support would be good) because it could vary by contribution, so it can't be stored singularly on the DWARFDebugMacro object since that represents multiple contributions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73086/new/

https://reviews.llvm.org/D73086