Compiler used: CLANG trunk GDB Version: trunk (GNU gdb (GDB) 11.0.50.20210606-git) ``` make check TESTS=gdb.base/macscp.exp RUNTESTFLAGS='"CC_FOR_TARGET=clang" CFLAGS_FOR_TARGET="-gdwarf-5 -gsplit-dwarf"' === gdb Summary === # of expected passes 234 # of unexpected failures 65 # of known failures 40 65 tests case failed while 234 testcases passing, this suggests some part of "-gsplit-dwarf" and macro machinery is still working great :) For a typical case one can observe the macro visible inside GDB: $ clang -fdebug-macro -gdwarf-5 -gsplit-dwarf ./macro.c ... gdb a.out -q Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x201664: file ./macro.c, line 2. Starting program: /home/sourabh/work/dwarf/c_c++/a.out Temporary breakpoint 1, main () at ./macro.c:2 2 int main() {} (gdb) info macros Defined at /home/sourabh/work/dwarf/c_c++/./macro.c:1 #define HELLO_GDB 1 Defined at /home/sourabh/work/dwarf/c_c++/./macro.c:-1 #define __FILE__ "/home/sourabh/work/dwarf/c_c++/./macro.c" Defined at /home/sourabh/work/dwarf/c_c++/./macro.c:-1 #define __LINE__ 2 ... Coming to 65 failures observed: We observed that, GDB doesn't reads the specialized line table from `.debug_line.dwo` section. Looking at the source code it seems to me that this is on purpose and `.debug_line.dwo` is only read if type units are present Code snippet from dwarf2/read.c ``` get_debug_line_section (struct dwarf2_cu *cu) /* For TUs in DWO files, the DW_AT_stmt_list attribute lives in the DWO file. */ if (cu->dwo_unit && cu->per_cu->is_debug_types) ``` Please note that `clang` emits specialized line table `.debug_line.dwo` for 2 cases: 1. For if type units are present (As per DWARFv5 spec) 2. For if `.debug_macro.dwo` section is present. DWARFIssue file to capture this http://dwarfstd.org/ShowIssue.php?issue=200602.1 **NOTE**: *Non-absolute/Relative* path still does not work(both split & no-split case) yet :( Patch in progress, needs clarification on the approach from maintainers. https://sourceware.org/pipermail/gdb-patches/2021-May/179190.html i.e ``` $ clang -fdebug-macro -gdwarf-5 -gsplit-dwarf macro.c gdb a.out -q Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x201664: file macro.c, line 2. Starting program: /home/sourabh/work/dwarf/c_c++/a.out Temporary breakpoint 1, main () at macro.c:2 2 int main() {} (gdb) info macros ```
(In reply to Sourabh Singh Tomar from comment #0) > **NOTE**: > *Non-absolute/Relative* path still does not work(both split & no-split case) > yet :( > Patch in progress, needs clarification on the approach from maintainers. > https://sourceware.org/pipermail/gdb-patches/2021-May/179190.html > > i.e > ``` > $ clang -fdebug-macro -gdwarf-5 -gsplit-dwarf macro.c > gdb a.out -q > Reading symbols from a.out... > (gdb) start > Temporary breakpoint 1 at 0x201664: file macro.c, line 2. > Starting program: /home/sourabh/work/dwarf/c_c++/a.out > > Temporary breakpoint 1, main () at macro.c:2 > 2 int main() {} > (gdb) info macros > ``` This should be fixed since this commit https://gitlab.com/gnutools/binutils-gdb/-/commit/7900b17e334b114ff149c5a3da7884e6ab3f7136 Can you confirm?
I usually move the bugs to "waiting" when there's a question. That way when we stumble over it again in N years we know we can just close it.
(In reply to Tom Tromey from comment #2) > I usually move the bugs to "waiting" when there's a question. > That way when we stumble over it again in N years we know we > can just close it. That's a good idea. However, here I'll move it to NEW (i.e. confirmed), because the main point of the bug is still valid. With the test binary generated with: $ make check TESTS=gdb.base/macscp.exp RUNTESTFLAGS="CC_FOR_TARGET=clang CFLAGS_FOR_TARGET='-gdwarf-5 -gsplit-dwarf'" I get: $ ./gdb -q -nx --data-directory=data-directory /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -ex "b macscp2_2" -ex r -ex "info macro WHERE" -batch ... The symbol `WHERE' has no definition as a C/C++ preprocessor macro at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/macscp2.h:22 included at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/macscp1.c:1 Whereas with: $ make check TESTS=gdb.base/macscp.exp RUNTESTFLAGS="CC_FOR_TARGET=clang" I get: $ ./gdb -q -nx --data-directory=data-directory /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -ex "b macscp2_2" -ex r -ex "info macro WHERE" -batch ... Defined at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/macscp2.h:16 included at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/macscp1.c:61 #define WHERE before macscp2_2