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

Mon Jul 6 13:26:13 PDT 2020

dblaikie added subscribers: JDevlieghere, labath.
dblaikie added a comment.

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.

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

Agreed.

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

Likely - but might want to check what GCC does - maybe it uses some kind of strx encoding that's not documented, etc.

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

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?)

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

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

https://reviews.llvm.org/D82975