[PATCH] D55091: Add --analyze option to llvm-dwarfdump

Thu Nov 29 18:06:42 PST 2018

vsk added a comment.

In D55091#1313877 <https://reviews.llvm.org/D55091#1313877>, @dblaikie wrote:

> In D55091#1313812 <https://reviews.llvm.org/D55091#1313812>, @vsk wrote:
>
> > In D55091#1313752 <https://reviews.llvm.org/D55091#1313752>, @dblaikie wrote:
> >
> > > What was the end result of the discussion around this and the other size analysis proposal (for objdump?) that came around the same time - and the overlap with Bloaty, for instance?
> >
> >
> > Reading the thread again (http://lists.llvm.org/pipermail/llvm-dev/2018-September/126501.html), istm that most folks were ok with having a size analysis tool in llvm. I pointed out some specific advantages (code reuse, shared maintenance) of having such a tool live in-tree. David suggested folding bloaty under the llvm umbrella -- my concern  (and IIRC @jakehehrlich's as well) was that doing so would amount to a full re-write. I've since switched teams to focus on outliner work, and haven't had time to whip my initial prototype into shape for upstreaming.
> >
> > > Would be good to have a goal - for instance, one of the things about binary size analysis is also looking at the reloc sizes for the debug info sections (& ultimately, probably looking at the whole object file/executable - including headers, etc, not just the section sizes themselves - for comparison purposes (optimizing debug info size only to realize there's something else holding up the object size tent would be unfortunate)).
> >
> > Agreed, I actually think this would make sense as part of a more comprehensive analysis mode in llvm-objdump.
>
>
> Do we want to split this sort of functionality between the two tools? I feel like that'd easily lead to people missing important things like the above example.

My suggestion/preference would be to consolidate the size analysis functionality in a single tool (llvm-objdump seems reasonable) to prevent the kind of confusion you’re describing here.

> (admittedly going from objdump to dwarfdump would probably be fine - you look at objdump's reports & go "oh, all my size cost is in debug info, let's find a tool that can tell me more about that" - but getting narrowly focussed on debug info and/or starting with dwarfdump size analysis & missing the bigger picture seems unfortunate)
> 
> Maybe even just having a "here are all the debug info section sizes - and here's a bucket for "all the rest of the file"" so you have a sense of relative size when you're looking at the dwarfdump results.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55091/new/

https://reviews.llvm.org/D55091