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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D82975#2138869 <https://reviews.llvm.org/D82975#2138869>, @dstenb wrote:

> 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 ?
>
>
> (Sorry, I don't have a GCC trunk build readily available, so I used GCC 9.3.0 here.)
>
> When using those flags, GCC seems to emit DW_MACRO_define_strp (DW_MACRO_GNU_define_indirect) entries, but with indexed strings as operands. Neither binutils nor GDB does consider that such entries may hold indexed strings, and just treats those operands as indirect strings, which is why they are not properly handled. "Overloading" those indirect operands with indexed strings seems very weird to me. Perhaps that is just a bug in GCC, rather than a limitation in the consumers?


Perhaps - though there was some thought put into supporting GNU debug_macro in v4/pre-standard Fission, given the DWP format had columns for both debug_macro and debug_macinfo ( https://gcc.gnu.org/wiki/DebugFissionDWP ). Don't think it's a big deal either way - if someone comes along wanting to add debug_macro support for pre-standard Fission, we can discuss what that format looks like at that point - happy enough for it to be unimplemented (& as I said before, have "-ggdb -gdwarf-4 -fdebug-macro -> debug_macro" and "-ggdb -gdwarf-4 -fdebug-macro -gsplit-dwarf -> debug_macinfo.dwo").


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

https://reviews.llvm.org/D82975