Created attachment 53614 [details] objdump output for dwarf-4 GCC 12 now defaults to outputting debug information via dwarf-5. Compared to dwarf-4 (which works), gdb's interpretation of dwarf-5 seems to show that we're missing the correct line information, which causes gdb to not be able to correctly find and evaluate a macro on the command line due to being in the wrong context. It's not clear whether gcc is not correctly emitting all the information, or if gdb is not correctly reading all the information. Breaking at the "main" function and attempting to run "info macro X" produces the error message, "The symbol `X' has no definition as a C/C++ preprocessor macro at macro.c:-1". The same behavior happens when breaking at any other point in a C program, and not just at "main". In both examples below, the breakpoint output shows we're at line 5 in macro.c: $ cat macro.c #define TEST_MACRO 42 int main() { return 0; } ### DWARF-4 Example ### $ gcc -O3 -ggdb3 -gdwarf-4 macro.c -o macro $ gdb macro GNU gdb (Gentoo 12.1 vanilla) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from macro... (gdb) break main Breakpoint 1 at 0x401020: file macro.c, line 5. (gdb) run Starting program: /g/macro [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main () at macro.c:5 5 return 0; (gdb) info macro TEST_MACRO Defined at /g/macro.c:1 #define TEST_MACRO 42 (gdb) p TEST_MACRO $1 = 42 (gdb) quit ### DWARF-5 EXAMPLE ### $ gcc -O3 -ggdb3 -gdwarf-5 macro.c -o macro $ gdb macro GNU gdb (Gentoo 12.1 vanilla) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from macro... (gdb) break main Breakpoint 1 at 0x401020: file macro.c, line 5. (gdb) run Starting program: /g/macro [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main () at macro.c:5 5 return 0; (gdb) info macro TEST_MACRO The symbol `TEST_MACRO' has no definition as a C/C++ preprocessor macro at /g/macro.c:-1 (gdb) p TEST_MACRO No symbol "TEST_MACRO" in current context. (gdb) quit Software versions: $ gdb -v GNU gdb (Gentoo 12.1 vanilla) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-12.2.0/work/gcc-12.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/12.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/12.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include/g++-v12 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/12.2.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 12.2.0 p1' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --enable-lto --without-isl --disable-libsanitizer --disable-default-pie --disable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Gentoo 12.2.0 p1) I've attached the output of "objdump -g macro" for both dwarf-4 and dwarf-5. Thanks!
Created attachment 53615 [details] objdump output for dwarf-5
I don't see anything wrong on what GCC emits. If I compile with -O3 -g3 -gdwarf-4 -dA -nostdinc so that stdc-predef.h isn't included vs. -O3 -g3 -gdwarf-5 -dA -nostdinc, in .debug_macro I see for DWARF 4: .section .debug_macro,"",@progbits .Ldebug_macro0: .value 0x4 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Ldebug_line0 .byte 0x7 # Import .long .Ldebug_macro2 .byte 0x3 # Start new file .byte 0 # uleb128 0; Included from line number 0 .byte 0x1 # uleb128 0x1; file pr107012.c .byte 0x5 # Define macro strp .byte 0x1 # uleb128 0x1; At line number 1 .long .LASF372 # The macro: "TEST_MACRO 42" .byte 0x4 # End file .byte 0 # End compilation unit where .Ldebug_macro2 is import of the predefined macros. .debug_line then has: .ascii "pr107012.c\0" # File Entry: 0x1 .byte 0 # uleb128 0 .byte 0 # uleb128 0 .byte 0 # uleb128 0 i.e. file entry 1 is pr107012.c. In DWARF 5 it is: .section .debug_macro,"",@progbits .Ldebug_macro0: .value 0x5 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Ldebug_line0 .byte 0x7 # Import .long .Ldebug_macro2 .byte 0x3 # Start new file .byte 0 # uleb128 0; Included from line number 0 .byte 0x1 # uleb128 0x1; file pr107012.c .byte 0x5 # Define macro strp .byte 0x1 # uleb128 0x1; At line number 1 .long .LASF374 # The macro: "TEST_MACRO 42" .byte 0x4 # End file .byte 0 # End compilation unit so there are only minor differences related to macros: - .long .Ldebug_macro0 # DW_AT_GNU_macros + .long .Ldebug_macro0 # DW_AT_macros in .debug_info section and .section .debug_macro,"",@progbits .Ldebug_macro0: - .value 0x4 # DWARF macro version number + .value 0x5 # DWARF macro version number .byte 0x2 # Flags: 32-bit, lineptr present .long .Ldebug_line0 .byte 0x7 # Import ... .byte 0x1 # uleb128 0x1; file pr107012.c .byte 0x5 # Define macro strp .byte 0x1 # uleb128 0x1; At line number 1 - .long .LASF372 # The macro: "TEST_MACRO 42" + .long .LASF374 # The macro: "TEST_MACRO 42" .byte 0x4 # End file .byte 0 # End compilation unit in .debug_macro. The line table then says that both file 0 and 1 are pr107012.c: .byte 0x2 # File name entry format count .byte 0x1 # uleb128 0x1; DW_LNCT_path .byte 0x1f # uleb128 0x1f; DW_FORM_line_strp .byte 0x2 # uleb128 0x2; DW_LNCT_directory_index .byte 0xb # uleb128 0xb; DW_FORM_data1 .byte 0x2 # uleb128 0x2; File names count .long .LASF0 # File Entry: 0: "pr107012.c" .byte 0 .long .LASF0 # File Entry: 0: "pr107012.c" .byte 0 You'd better file this against gdb...
*** Bug 107414 has been marked as a duplicate of this bug. ***
See https://sourceware.org/pipermail/gdb-patches/2022-April/187555.html So moved to the gdb bug.