I see that llvm-readobj displays information similar to GNU readelf does except DWARF data. I also see llvm-dwarfdump dumps all DWARF data in user readable format. Is there a plan for readobj to incorporate similar options? This will make readobj more feature complete for reading objects similar to readelf.
If this is not the plan, will llvm-dwarfdump be a tool that regular user can use and rely on or it is only for compiler/tools developers?
My vote (and long term-plan, if there's consensus) is for integrating
dwarfdump into readobj and just get rid of llvm-dwarfdump (or make it
a tiny wrapper around llvm-readobj), similarly to what I recently did
with macho-dump. There's seriously no need to duplicate functionality
across tools. An analogous argument holds for llvm-readobj and
I see no harm in integrating llvm-dwarfdump implementation into llvm-readobj, as long as we keep the functionality of dumping only the specified
debug info sections. Also, there is no need in removing the binary - we may just keep llvm-dwarfdump an alias of llvm-readobj, probably with
a different defaults: see the way llvm-ar/llvm-ranlib/llvm-lib are created.
One of the goals for llvm-dwarfdump that have been discussed previously on this list and on #llvm is to add more options that tweak the output to make it more amenable to testing with FileCheck. Another goal is to replicate more features of the Darwin “dwarfdump” utility, such as the —verify mode and the ability to dump only a specific DIE (and all of its parents or children or both). I’m also planning to add support for dumping .dSYM bundles in the near future.
It’s possible that some of these features make also sense under the readobj umbrella, but personally I’d rather have an llvm-dwarfdump as a separate tool to keep the command line option namespace simple.