[PATCH] D82975: [DebugInfo] Allow GNU macro extension to be emitted

[David Stenberg via Phabricator via llvm-commits]

dstenb added a comment.

In D82975#2134132 <https://reviews.llvm.org/D82975#2134132>, @dblaikie wrote:

> In D82975#2128353 <https://reviews.llvm.org/D82975#2128353>, @dstenb wrote:
>
> > In D82975#2127201 <https://reviews.llvm.org/D82975#2127201>, @SouraVX wrote:
> >
> > > > When you say 'by default' - do you mean by default when the user requests macro debug info (via -fdebug-macro) or by default without any extra flag?
> > > > & what does GCC do? Does it have a way to emit the standard debug_macinfo in v4 and below? Or does it always emit the debug_macro GNU extension?
> > >
> > > I'm not particularly sure of this(introduction of GNU encodings). Behavior of GCC trunk(11.0.0) is as follows:
> > >
> > > `gcc -g3 test.c -c`, after dumping using `objdump(2.32)`, GCC will create `.debug_macro`(sort of it's default, until you specify `-gstrict-dwarf` in which case GCC will generate `.debug_macinfo`).
> >
> >
> > As Sourabh says this is default when not emitting strict DWARF in GCC. For Clang, my intention was for it to be enabled by default for `-fdebug-macro` when tuning for GDB. Maybe it would also be interesting when tuning for LLDB?
>
>
> Sounds alright. Not sure if the LLDB folks (@aprantl @JDevlieghere @labath) would be interested in that - a separate patch in any case.


Yes, let's take that in another patch.

>> I just want to add that one downside with emitting `.debug_macro` that we have noticed downstream is that size of archives can grow quite a bit, since you then both pay for the uncoalesced strings in the different object files (same cost as for `.debug_macinfo`), plus all of the relocations.
> 
> Got a rough %? Is it easy to disable this functionality if someone were trying to optimize for object size? (is there an easy way to disable gdb tuning on platforms that default to it, for instance?)

I wrote that because I have in some downstream cases seen the size of large archives more than double. I don't know if there is something special about those cases, or the cost of relocation on that target, though.

When building a Clang 8.0 RelWithDebInfo binary on x86-64 the size of the archives under lib/ increased from 5224M to 5341M (a 2.4% increase), so that's not too bad.

  $ du -h -s build-lib-with-macinfo/*.a | sort -h | tail -10
  152M	build-lib-with-macinfo/libclangARCMigrate.a
  194M	build-lib-with-macinfo/libclangStaticAnalyzerCore.a
  200M	build-lib-with-macinfo/libLLVMX86CodeGen.a
  230M	build-lib-with-macinfo/libLLVMAnalysis.a
  245M	build-lib-with-macinfo/libLLVMScalarOpts.a
  289M	build-lib-with-macinfo/libclangAST.a
  457M	build-lib-with-macinfo/libclangSema.a
  481M	build-lib-with-macinfo/libclangCodeGen.a
  535M	build-lib-with-macinfo/libLLVMCodeGen.a
  573M	build-lib-with-macinfo/libclangStaticAnalyzerCheckers.a
  
  $ du -h -s build-lib-with-macro/*.a | sort -h | tail -10
  154M	build-lib-with-macro/libclangARCMigrate.a
  197M	build-lib-with-macro/libclangStaticAnalyzerCore.a
  204M	build-lib-with-macro/libLLVMX86CodeGen.a
  237M	build-lib-with-macro/libLLVMAnalysis.a
  250M	build-lib-with-macro/libLLVMScalarOpts.a
  295M	build-lib-with-macro/libclangAST.a
  460M	build-lib-with-macro/libclangSema.a
  487M	build-lib-with-macro/libclangCodeGen.a
  548M	build-lib-with-macro/libLLVMCodeGen.a
  581M	build-lib-with-macro/libclangStaticAnalyzerCheckers.a

Regarding overriding the default, I think the only way is to explicitly pass another tuning option, e.g. `-glldb`?


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

https://reviews.llvm.org/D82975