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

[Sourabh Singh Tomar via Phabricator via llvm-commits]

SouraVX added a comment.

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

> In D82975#2134347 <https://reviews.llvm.org/D82975#2134347>, @probinson wrote:
>
> > 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:
> > > >
> > > > > 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.
> >
> >
> > My recollection is that .debug_macro was invented independently of the strx forms so the prototype probably wouldn't have used them.  Easy enough to check whether GCC's `-fdebug-macro` with v4 is emitting a .debug_str_offsets section.
> >
> > LLVM wouldn't be using strx forms from .debug_info for v4, and would have no other reason to emit .debug_str_offsets, so I wouldn't want LLVM to use them in a v4 compatibility mode .debug_macro section either.
>
>
> GCC certainly seems to produce some kind of debug_macro.dwo section (& binutils dwp supports it in the index, if I recall correctly) using some form llvm-dwarfdump currently doesn't understand:
>
>   $ g++-tot -g3 main.cpp -c -gsplit-dwarf && llvm-objdump -h main.dwo | grep " \.debug"
>     1 .debug_info.dwo        0000003c 0000000000000000 
>     2 .debug_abbrev.dwo      0000003e 0000000000000000 
>     3 .debug_macro.dwo       0000001e 0000000000000000 
>     4 .debug_macro.dwo       00000364 0000000000000000 
>     5 .debug_macro.dwo       00000013 0000000000000000 
>     6 .debug_line.dwo        00000048 0000000000000000 
>     7 .debug_str_offsets.dwo 000002d5 0000000000000000 
>     8 .debug_str.dwo         00000e05 0000000000000000 
>   $ llvm-dwarfdump-tot main.dwo -debug-macro
>   main.dwo:       file format elf64-x86-64
>  
>   .debug_macro.dwo contents:
>   0x00000000:
>    - lineno: 19 macro: 
>   DW_MACINFO_invalid
>
>
> I mean, I don't have strong feelings about supporting macro debug info in general, but if someone feels strongly about debug_macro GNU extension DWARFv4 support, there's certainly some GCC behavior that one could use to model the Split DWARF support for that off.


One more deciding factor to considered here(previously missed) is that: `GDB(trunk)` also doesn't understand `GNU macro extensions`(if you wish to call it) in split case.
i.e 
`gcc -g3 -gsplit-dwarf test.c`
`test.dwo` contains `.debug_macro.dwo` forms which no tool(as of now can dump).
if you load `a.out`  in GDB and try expanding macro(defined in source).
GDB will report

  (gdb) info macro FOO
  The symbol `FOO' has no definition as a C/C++ preprocessor macro
  at <user-defined>:-1

on the other hand, if you try with `-gstrict-dwarf -gsplit-dwarf`. GDB is happy.
So at the end of the day, even if we allow `GNU macro` extension, things will still be broken for `-gsplit-dwarf` case. 
Or we have to teach the debugger to understand this ?, this also hinges on the fact, what kinda form GCC uses in split-case in `.debug_macro.dwo` section. 
That it self is unclear right ?


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

https://reviews.llvm.org/D82975