Take this code: union node { struct { int a; } l; } x; #define memory l.a int main() { return x.memory; } When compiled with -gdwarf-4 -g3 and run in gdb, it is possible to use Breakpoint 1, main () at u.c:11 11 return x.memory; (gdb) p x.memory $1 = 0 When instead -gdwarf-5 -g3 is used 'memory' is not known to be a macro and one gets Breakpoint 1, main () at u.c:11 11 return x.memory; (gdb) p x.memory There is no member named memory. Shouldn't the Dwarf 5 data be a superset of what Dwarf 4 provides? This is not new in the trunk/13 version. 12.1 fails as well and likely prior versions, too.
Just skimming -dA -gdwarf-4 -g3 and -dA -gdwarf-5 -g3 assembly differences, I don't see anything wrong on the compiler side. So, I think it is much more likely this is a gdb bug.
OK, I submitted: https://sourceware.org/bugzilla/show_bug.cgi?id=29725 Let's see what they say.
Dup of bug 107012 *** This bug has been marked as a duplicate of bug 107012 ***
Actually, Jakub was right. This is a gdb issue. The gdb maintainers pointed me to the trunk version and this indeed works with this simple code sequence. There might have been a bug as in 107012 but even after that fix gdb didn't handle the dwarf data correctly before a recent commit.
The original reproducer Ulrich gave indeed seems like what was fixed in GDB master recently. Macros in the main source file didn't work with DWARF 5. That works fine now. But he pointed me to a real-life case in gawk, where it didn't work: https://sourceware.org/bugzilla/show_bug.cgi?id=29725#c2 That seems to highlight a new problem, that is the use of macros combined with #line directives. I don't think that the debug info is sufficient for GDB to figure this out. For convenience, here's a copy of what I posted on the GDB bug. --- With a simple case, it works as expected: $ cat test.c #define FOO 2 int main() { return FOO; } $ gcc test.c -g3 -O0 $ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled off" ./a.out -ex start -ex "info macro FOO" -batch ... Defined at /home/simark/build/binutils-gdb/gdb/test.c:1 #define FOO 2 But then if you add a line control directive, like you have for a .c file generated from a .y file: $ cat test.c #define FOO 2 #line 17 "potato.c" int main() { return FOO; } $ gcc test.c -g3 -O0 $ ./gdb --data-directory=data-directory -nx -q -iex "set debuginfod enabled off" ./a.out -ex start -ex "info macro FOO" -batch ... The symbol `FOO' has no definition as a C/C++ preprocessor macro at /home/simark/build/binutils-gdb/gdb/test.c:-1 Looking at the macro debug info (my annotations after the #s): $ readelf --debug-dump=macro a.out DW_MACRO_import - offset : 0x20 # built-in macros DW_MACRO_start_file - lineno: 0 filenum: 2 # test.c DW_MACRO_start_file - lineno: 0 filenum: 3 # stdc-predef.h DW_MACRO_import - offset : 0x900 # STDC macros DW_MACRO_end_file # end of stdc-predef.h DW_MACRO_define_strp - lineno : 1 macro : FOO 2 <--- here DW_MACRO_end_file # end of test.c The line table tells GDB that the current PC is in potato.c, line 17: CU: ./test.c: File name Line number Starting address View Stmt potato.c 17 0x1119 x potato.c 17 0x111d x potato.c 17 0x1122 x potato.c - 0x1124 But GDB has no way to figure out where this is in the macro inclusion tree, as potato.c is never represented in there. Ideally, GDB would figure out that we are where I maked `here`, above. Looking at the DWARF opcodes for macro, I don't really see a way to describe the #line stuff. There's only DW_MACRO_start_file, which represents the inclusion of a complete file.