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

[Sourabh Singh Tomar via Phabricator via llvm-commits]

SouraVX added a subscriber: probinson.
SouraVX added a comment.

> 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`).

The only difference b/w `-g3` and `-gdwarf-5 -g3` GCC generated `.debug_macro` section is the `version` information in `macro header`, `4` and `5` respectively. However there's no difference in encoding used i.e both uses (DWARFv5 encodings) there is no `DW_MACRO_GNU*` -- observed using binutils `objdump` version info mentioned above.

And lastly The reason why current `llvm-dwarfdump` is not able to dump/parse GCC generated(`gcc -g3 test.c -c`) `.debug_macro` section is because it uses `version` information in the header to parse it correctly(In this case it is `4`). However if you generate the macro info as(specifying version) `gcc -gdwarf-5 -g3 test.c -c` llvm-dwarfdump can parse/dump it correctly.

I think if it's about compatibility(analogous behavior with GCC), existing infra is Okay/Fine(Since same encodings are used). We just need to emit the `.debug_macro` section with `version` 4 and teach the `llvm-dwarfdump` to parse it correctly.

> The size of a Clang 8.0 binary built with RelWithDebInfo and the flags "-gdwarf-4 -fdebug-macro" reduces from 1533 MB to 1349 MB with .debug_macro (compared to 1296 MB without -fdebug-macro).

Yes that's good motivation for this patch, I also observed this in our initial findings, but I was occupied with current v5 split macro stuff.
`CLANG/llvm` AFAIK doesn't have `-gstrict-dwarf`. So if you want analogous behavior like GCC(have `.debug_macro` section even at version `4`) you may need to introduce extra flag/switch. So that if end-user still `.debug_macinfo` for whatever reasons CLANG/llvm should generate it.
 I'm not the right person these sort of decision, I'll leave it to @dblaikie and @probinson .

> One thing that I have not looked into yet is what to do in the DWO case (when using -gsplit-dwarf). We can't use relocations in the .debug_macro.dwo section, so the indirect strp entries are not viable there.

Yes, that's broken in GCC too, sort of it produces encodings that not even `objdump` can understand.
`objdump` produces following Error comes when you dump `.dwo` file:

  .debug_macro section not zero terminated
  objdump: Error:  Unknown macro opcode 23 seen
  objdump: Error:  Unknown macro opcode de seen

I've done some initial work(in llvm) around that D78866 <https://reviews.llvm.org/D78866> and related. This is still broken from emission perspective(Fix in progress). `llvm-dwarfdump` works great.

Anyway Thanks for the patch :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82975