Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers,
this patch adds support for zlib style.
It looks reasonable to support both styles for dumping,
even if we are not going to suport generating of deprecated gnu one.
Details
- Reviewers
dblaikie davide • rafael - Commits
- rG401e4e570e1e: Recommit r270547 ([llvm-dwarfdump] - Teach dwarfdump to decompress debug…
rGe9b2e19109d9: Recommit r270540 fix: forgot to commit the updated dwarfdump-test-zlib.elf-x86…
rG6bcbf4c572c2: [llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.
rL270557: Recommit r270547 ([llvm-dwarfdump] - Teach dwarfdump to decompress debug…
rL270543: Recommit r270540
rL270540: [llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Commit message typo: "depricated" should be "deprecated". Probably also
missing a "we" before [or use "it is" instead of] "are" in the last line.
Mats
Generally looks good. I'm not sure about renaming the zdebug section to debug in the output, but I'm not set against it either.
lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
626 ↗ | (On Diff #57931) | You could just increment Offset (by sizeof(Elf64_Word)) here, I think? |
681–685 ↗ | (On Diff #57931) | This involves making extra copies of the data. Is there a reason you went with this over the original code that decompressed straight into the UncompressedSections? |
- Addressed review comments.
lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
626 ↗ | (On Diff #57931) | Right. |
681–685 ↗ | (On Diff #57931) | My point was to avoid possible calls of pop_back right after resize if decompression fails. I just forgot to use std::move() to avoid extras when rewrote. Fixed. There should be no more extra heap allocations here. |
Except this defeats/comes at a cost of the small vector optimization - std::move on a small vector in small mode is the same as a copy.
Sorry, perhaps I should've commented the original code to explain/justify it better.
- David
Small mode for small vector in this place is when it's size less than 32 bytes, right ?
Should we really care of this for the sake of simplicity of code ? I mean that for debug sections 32 bytes
is probably almost never a option, they usually should be greater anyways I think.
Just in case - I plan to revert to initial logic of this soon and update the patch, as it does not affect the main logic
and we can land patch separatelly and return to this place later if we want to.
George.
- Restored original way to work with UncompressedSections vector, it is unrelated to this patch.
Looks good - thanks!
test/DebugInfo/Inputs/dwarfdump-test-zlib.cc | ||
---|---|---|
24 ↗ | (On Diff #58084) | Might be worth including in the comment some detail about how you verified that the output did actually contain compressed sections (just that the size of the output is smaller, for example) in both cases? (I realize this was missing originally as well, but some paper trail seems helpful to add) |