There are many different types of debug info about modules, such as line information, checksum information, symbol info, etc. in the existing code, we have a single "visitor" class which knows how to parse all the different types, and invokes a callback interface with the results.
Once we begin trying to write this information, this monolithic model becomes difficult to work with, because reading and writing share enough similarities that they should be grouped together whenever possible, but enough differences that you can't always do an exact mapping of the code.
For this reason, it would help if the knowledge of how to parse each type of module debug info fragment were isolated from the others in its own class. This way we could provide useful accessors on these classes for querying fields from the parsed format, or iterating over fields with ranged based fors, or methods to add new items to a list.
In short, the individual fragment types are complicated enough that it makes sense to have their knowledge wrapped up in individual classes designed to be able to query / manipulate / deserialize / serialize them.
In doing so, I found an instance where parsing code was duplicated. Once in llvm-readobj which had its own code for parsing the FileChecksums fragment, and once in llvm-pdbdump where it used the code in DebugInfo/CodeView to do the same thing. When the llvm-readobj code to use the CodeView code (which made the code much simpler), this surfaced a bug in the CodeView implementation where we did not account for alignment, so this has been fixed as well.