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

Thu Jul 2 08:38:02 PDT 2020

dstenb added a comment.

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?

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

I personally think that the binutils tools printing the GNU extension using DWARF 5 entry names is confusing, but if people prefer to have it like that to avoid the larger code changes that this patch series introduce, I can align with that.

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

One difference though is that the GNU extension does not have anything like the strx entries that LLVM currently emits: https://github.com/gcc-mirror/gcc/blob/master/include/dwarf2.h#L425, so I assume we still need code to emit the strp entries when targeting DWARF 4?

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

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.

Other than that I am personally not aware of any other major reasons for wanting to use `.debug_macinfo` over `.debug_macro`, given that the rest of the toolchain supports the latter format, of course.

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

Okay, thanks for the information!

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82975