llvm dev - Sep 2015 - DWARF info in readobj

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