With board cc-with-debug-names I see these failures: ... FAIL: gdb.dwarf2/dw2-ranges-base.exp: info line main FAIL: gdb.dwarf2/dw2-ranges-base.exp: info line frame2 FAIL: gdb.dwarf2/dw2-ranges-base.exp: info line frame3 FAIL: gdb.dwarf2/dw2-ranges-func.exp: disassemble foo (pattern 2) FAIL: gdb.mi/dw2-ref-missing-frame.exp: test func_nofb_marker (timeout) FAIL: gdb.mi/dw2-ref-missing-frame.exp: test func_loopfb_var (timeout) ...
> FAIL: gdb.dwarf2/dw2-ranges-base.exp: info line main a. In more detail: ... Breakpoint 1, 0x00000000004004be in main ()^M (gdb) info line main^M No line number information available for address 0x4004ba <main>^M FAIL: gdb.dwarf2/dw2-ranges-base.exp: info line main ... Things go wrong when we call dw2_find_pc_sect_compunit_symtab, which tries to find the address of main in the psymtabs_addrmap: ... data = (struct dwarf2_per_cu_data *) addrmap_find (objfile->partial_symtabs->psymtabs_addrmap, pc - baseaddr); ... The psymtabs_addrmap has been initialized by create_addrmap_from_aranges, using the .debug_aranges section. The test-case is a dwarf assembly one, and the dwarf assembler does not seem to generate .debug_aranges: ... $ grep .section.*.debug_ dw2-ranges-base-dw.S .section .debug_info .section .debug_line .section .debug_ranges .section .debug_abbrev ... The executable contains dwarf from various init code (on openSUSE Leap 15.0), so the executable actually does contain a .debug_aranges section: ... $ readelf -SW dw2-ranges-base | grep .debug_aranges [25] .debug_aranges PROGBITS 0000000000000000 0010b0 000100 00 0 0 16 ... Either way, addrmap_find returns 0 because there's no .debug_aranges info related to main, and that propagates further to the point of "info line main" failing. b. On an ubuntu 18.04 system, the test-case does not fail. The executable does not contain a .debug_aranges section, and the effect seems to be that gdb-add-index adds an empty (though not size-0) .debug_names section. When using this exec, gdb ignores the empty .debug_names section, which allows the test to pass (similar to how it passes when the test-case is run natively as opposed to using cc-with-debug-names). So, I wonder: ad a. Should gdb handle partially missing .debug_aranges info more gracefully? The case we trigger here seems to be that the dwarf assembler is a "compiler that does not generate .debug_aranges sections" as described here ( http://wiki.dwarfstd.org/index.php?title=Best_Practices#Generating_.debug_aranges_data ). The point of the consumer (i.e. gdb) being able to distinguish between "a compilation unit that has no ranges" and "a compilation unit generated by a compiler that does not generate .debug_aranges sections" seems to be to handle it gracefully, which AFAIU we currently don't. ad b. Is it a bug that we generate an empty .debug_names section in this case?
(In reply to Tom de Vries from comment #0) > With board cc-with-debug-names I see these failures: > ... > FAIL: gdb.mi/dw2-ref-missing-frame.exp: test func_nofb_marker (timeout) > FAIL: gdb.mi/dw2-ref-missing-frame.exp: test func_loopfb_var (timeout) > ... Fixed here ( https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=54ac3df1adbf7b4b3470a8df08caa0aea4c89616 ).
None of these seem to fail for me now.