This fixes printing long values that might reside in CIE and FDE, including offsets, lengths, and addresses.
Apologies for the slow response. Overall this seems cleaner than D73714, now that I better understand the subtleties between .debug_frame and .eh_frame specifications.
The commit message should include a link to the Linux spec that you cited in the other review, which will help future readers understand the differences between the two formats.
A couple of minor things inline that I would like to see addressed.
Because this will not return the value from the data, it should have a comment along the lines of:
This looks like you are printing LinkedCIEOffset twice?
I've moved the method (now a function) getCIEId() to D73886. The comment is added there.
Thanks for catching that! It was an issue in our implementation, I've prepared D74613 to fix that.
For completeness, you probably want DWARF32 versions of these too.
clang-format-recognised style is /*IsDWARF64=*/true.
Same principle applies throughout.
I believe there's no need for the ULL suffix here and elsewhere below.
As the TestCIE block is practically identical in all test cases, it might be good to pull it into a function e.g. createCIE(uint64_t Length, uint64_t Offset). This will also make clearer what is actually important to each test case.
A side note. It looks like clang-format recognizes both styles, and both are used in the LLVM codebase, but the condensed variant is way more widespread and also is mentioned in the LLVM Coding Standards (not as a requirement, just as an example).
P.S. please remember to mark inline comments as "Done" using the checkbox once you address something. If you do that before uploading a patch, they will get automatically submitted when the patch is uploaded.
When you say "recognises" I think what happens is that it treats the old style as a normal inline comment, so applies the normal comment formatting rules. That is based purely on observation though, so I could be completely wrong!
Well, maybe it does not need to recognize them in a special way if the result of the formatting is the same as expected. Anyway, I agree that it is better to stick with a more widespread style despite my personal taste.