Summary: | cc-with-debug-names FAILs | ||
---|---|---|---|
Product: | gdb | Reporter: | Tom de Vries <vries> |
Component: | gdb | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | pedro, simark, tromey |
Priority: | P2 | ||
Version: | HEAD | ||
Target Milestone: | 15.1 | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Tom de Vries
2019-06-21 09:36:23 UTC
> 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. |