Hi All, 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? -- Hemant Kulkarni khemant at codeaurora.org Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150915/68920490/attachment.html>
On Tue, Sep 15, 2015 at 12:16 PM, Hemant Kulkarni via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi All, > > > > 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 llvm-objdump. My $0.02, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
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. On Tue, Sep 15, 2015 at 12:53 PM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Tue, Sep 15, 2015 at 12:16 PM, Hemant Kulkarni via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > > > > > > > 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 > llvm-objdump. > > My $0.02, > > -- > Davide > > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Alexey Samsonov vonosmas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150915/80d2f640/attachment.html>
> On Sep 15, 2015, at 12:53 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, Sep 15, 2015 at 12:16 PM, Hemant Kulkarni via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi All, >> >> >> >> 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 > llvm-objdump.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. -- adrian
Seemingly Similar Threads
- [llvm-readobj][RFC]Making llvm-readobj GNU command-line compatible
- [llvm-readobj][RFC]Making llvm-readobj GNU command-line compatible
- [RFC][binutils] Machine-readable output from Binutils - possible GSOC project?
- [RFC] Support disassembly of ARM and thumb mixed in single ELF file
- RFC: llvm-readelf Mach-O & COFF options