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

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 29 17:56:00 PST 2018


dblaikie added a comment.

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. (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





More information about the llvm-commits mailing list