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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D82975#2135150 <https://reviews.llvm.org/D82975#2135150>, @SouraVX wrote:

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


Sure, but easy enough to find the answer to by looking at GCC's output or implementation.

But, yeah, hardly high-value if gdb doesn't support it anyway, unless someone wants to add support there, or has some other DWARF Consumer that can handle it.

Don't mind -gsplit-dwarf -gdwarf-4 -fdebug-macro -ggdb to use debug_macinfo.dwo while non-split uses GNU extension debug_macro. Don't mind hugely in any case.


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

https://reviews.llvm.org/D82975