[Bug gdb/24716] New: cc-with-debug-names FAILs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24716] New: cc-with-debug-names FAILs

Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24716

            Bug ID: 24716
           Summary: cc-with-debug-names FAILs
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

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)
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24716] cc-with-debug-names FAILs

Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24716

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com,
                   |                            |simark at simark dot ca,
                   |                            |tromey at sourceware dot org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
> 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?

--
You are receiving this mail because:
You are on the CC list for the bug.