[Bug symtab/32658] New: GDB sometimes fails parsing debug information

[Bug symtab/32658] New: GDB sometimes fails parsing debug information

[pixel@nobis-crew.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

            Bug ID: 32658
           Summary: GDB sometimes fails parsing debug information
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: pixel@nobis-crew.org
  Target Milestone: ---

Created attachment 15930
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15930&action=edit
Test elf file which fails parsing its debug information

I've yet to fully investigate what's going on, but I figured I'd start by
reporting what I have so far in case someone already has some ideas.

Since commit 3d20b8d99a54382e6e1a6c433e71e0775c6856c6 which introduced the new
DWARF indexer, some of the ELF files I'm producing using normal gcc aren't able
to display their debug information anymore. I've attached one of these ELF
files as an example.

Before the new DWARF indexer, with this ELF file, I can do this properly:

(gdb) info line *0x800334b0
Line 44 of "src/application.cpp" starts at address 0x800334b0
<_ZN5psyqo11Application3runEv>
   and ends at 0x800334bc <_ZN5psyqo11Application3runEv+12>.

After this commit however, I get the following:

(gdb) info line *0x800334b0
No line number information available for address 0x800334b0
<_ZN5psyqo11Application3runEv>

and this is true for most of the addresses of the binary. My current working
theory is some pieces of code sometimes produce debug information which gdb
can't parse properly, and that its parser just stops mid-way.

To better demonstrate what I am talking about instead of just using the info
line command, this binary in particular has an assert mid-processing, and with
a gdb built after this commit, I get the following stacktrace:

(gdb) bt
#0  0x8003e7f0 in pcsx_debugbreak ()
#1  0x8003eb90 in check_subintegrity ()
#2  0x8003ef9c in check_integrity ()
#3  0x8003f73c in psyqo_free ()
#4  0x80010a68 in free ()
#5  0x8002f49c in l_alloc ()
#6  0x8001a270 in luaM_realloc_ ()
#7  0x8001d714 in luaH_resize ()
#8  0x8001d8e0 in rehash ()
#9  0x8001db90 in luaH_newkey ()
#10 0x8001e140 in luaH_set ()
#11 0x80026490 in luaX_newstring ()
#12 0x80028f20 in llex ()
#13 0x800290dc in luaX_next ()
#14 0x8002ea8c in funcstat ()
#15 0x8002ef7c in statement ()
#16 0x8002bc40 in statlist ()
#17 0x8002f154 in mainfunc ()
#18 0x8002f324 in luaY_parser ()
#19 0x80014ee4 in f_parser ()
#20 0x800135ac in luaD_rawrunprotected ()
#21 0x80014c08 in luaD_pcall ()
#22 0x80015094 in luaD_protectedparser ()
#23 0x80011f5c in lua_load ()
#24 0x8002f458 in luaL_loadbufferx ()
#25 0x800109a8 in (anonymous namespace)::LuaScene::frame() ()
#26 0x80033608 in psyqo::Application::run() ()
#27 0x80010a40 in main ()
(gdb)

However, if I run a gdb prior to that commit, I get the following:

(gdb) bt
#0  pcsx_debugbreak () at
/home/pixel/sources/lua-derp/third_party/nugget/common/hardware/pcsxhw.h:32
#1  0x8003eb90 in check_subintegrity (first=0x80046240, top=0x80046940,
size_start=8, hypothetical_size=1800)
    at src/alloc.c:131
#2  0x8003ef9c in check_integrity () at src/alloc.c:200
#3  0x8003f73c in psyqo_free (ptr_=0x80046948) at src/alloc.c:408
#4  0x80010a68 in free (ptr=0x80046948) at lua.cpp:97
#5  0x8002f49c in l_alloc (ud=0x0, ptr=0x80046948, osize=20, nsize=0) at
lauxlib.c:754
#6  0x8001a270 in luaM_realloc_ (L=0x80045e90, block=0x80046948, osize=20,
nsize=0) at lmem.c:84
#7  0x8001d714 in luaH_resize (L=0x80045e90, t=0x800468d8, nasize=0, nhsize=2)
at ltable.c:331
#8  0x8001d8e0 in rehash (L=0x80045e90, t=0x800468d8, ek=0x80046020) at
ltable.c:356
#9  0x8001db90 in luaH_newkey (L=0x80045e90, t=0x800468d8, key=0x80046020) at
ltable.c:413
#10 0x8001e140 in luaH_set (L=0x80045e90, t=0x800468d8, key=0x80046020) at
ltable.c:512
#11 0x80026490 in luaX_newstring (ls=0x801ffb50,
    str=0x800468b0 "native_callback_loopUso\215\030\004+▌\004'b- i\004\200(",
l=20) at llex.c:127
#12 0x80028f20 in llex (ls=0x801ffb50, seminfo=0x801ffb60) at llex.c:492
#13 0x800290dc in luaX_next (ls=0x801ffb50) at llex.c:519
#14 0x8002ea8c in funcstat (ls=0x801ffb50, line=3) at lparser.c:1470
#15 0x8002ef7c in statement (ls=0x801ffb50) at lparser.c:1558
#16 0x8002bc40 in statlist (ls=0x801ffb50) at lparser.c:609
#17 0x8002f154 in mainfunc (ls=0x801ffb50, fs=0x801ffb8c) at lparser.c:1610
#18 0x8002f324 in luaY_parser (L=0x80045e90, z=0x801ffd10, buff=0x801ffca8,
dyd=0x801ffcb4, name=0x80041810 "?",
    firstchar=102) at lparser.c:1630
#19 0x80014ee4 in f_parser (L=0x80045e90, ud=0x801ffca4) at ldo.c:661
#20 0x800135ac in luaD_rawrunprotected (L=0x80045e90, f=0x80014d48 <f_parser>,
ud=0x801ffca4) at ldo.c:141
#21 0x80014c08 in luaD_pcall (L=0x80045e90, func=0x80014d48 <f_parser>,
u=0x801ffca4, old_top=8, ef=0) at ldo.c:613
#22 0x80015094 in luaD_protectedparser (L=0x80045e90, z=0x801ffd10,
name=0x80041810 "?", mode=0x0) at ldo.c:682
#23 0x80011f5c in lua_load (L=0x80045e90, reader=0x8002f380 <getS>,
data=0x801ffd48, chunkname=0x80041810 "?",
    mode=0x0) at lapi.c:979
#24 0x8002f458 in luaL_loadbufferx (L=0x80045e90,
    buff=0x8004442c <this_code_causes_blackscreen> "function
native_callback_init(game, w, h)\nend\nfunction
native_callback_loop(dt)\nend\nfunction native_callback_draw()\n   
native_draw_rect(0, 10, 10, 20, 20)\nend\n", size=160,
    name=0x80041810 "?", mode=0x0) at lauxlib.c:519
#25 0x800109a8 in (anonymous namespace)::LuaScene::frame (this=0x80045258
<(anonymous namespace)::luaScene>)
    at lua.cpp:85
#26 0x80033608 in psyqo::Application::run (this=0x80044800 <(anonymous
namespace)::lua>) at src/application.cpp:58
#27 0x80010a40 in main () at lua.cpp:93

Note this happens on a per-binary basis. Some binaries will display their debug
information properly in gdb, some others will not, and I have yet to narrow
down what makes it so. All binaries have been built using the same exact
compilation flags, so I don't think it's very relevant, and that instead it's
about the contents of said code causing the issue, but let me know if you want
to be able to reproduce this yourself, and I'll happily share some test
repository. It'll contain a lot of code however.

I'm now going to try debugging a bit inside of gdb to see if my theory is
correct and what kind of DWARF/DIE record makes gdb choke.

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sam at gentoo dot org,
                   |                            |tromey at sourceware dot org

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |29366


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=29366
[Bug 29366] [meta] New DWARF indexer meta bug
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/32658] GDB sometimes fails parsing debug information

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
I'm not sure I can readily run this, unless you have some kind
of qemu recipe I can follow.

Anyway turning on complaints and -readnow says some stuff:

During symbol reading: in /tmp/test-gdb.elf, DIE 0xc, DW_AT_entry_pc (0x0)
outside block range (0x80010064 -> 0x80011888)
During symbol reading: .debug_rnglists entry has start address of zero [in
module /tmp/test-gdb.elf]
During symbol reading: .debug_line address at offset 0x25d3 is 0 [in module
/tmp/test-gdb.elf]
During symbol reading: cannot get low and high bounds for subprogram DIE at
0x1a9d0


These are suggestive but I'm not really sure they are the bug.

Reading the DWARF seems to be fine.  I'd suspect maybe something
with the line tables or blockvector.

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[pixel@nobis-crew.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

--- Comment #2 from Nicolas Noble <pixel@nobis-crew.org> ---
You shouldn't need to run it, really, to see the problem. Just loading the
binary into gdb and doing info line *0x800334b0 for instance is enough.

But if you really want to run this binary however, this is a PlayStation 1
software, which you'd need to run within an emulator with gdb support, and that
could potentially be more involved than using qemu. However, you can check the
one I'm the maintainer of here:
https://github.com/grumpycoders/pcsx-redux/?tab=readme-ov-file#where

Starting the emulator with the gdb server enabled is as simple as running this
command:

$ ./PCSX-Redux.appimage -stdout -interpreter -debugger -gdb 

Then, from gdb itself:

$ gdb test-gdb.elf
(gdb) target remote localhost:3333
(gdb) monitor reset shellhalt
(gdb) load test-gdb.elf
(gdb) cont

It'll display a lot of debugging information on stdout before eventually
triggering a breakpoint.

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[qqxnjvamvxwx at dyxyl dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

Martin Simmons <qqxnjvamvxwx at dyxyl dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qqxnjvamvxwx at dyxyl dot com

--- Comment #3 from Martin Simmons <qqxnjvamvxwx at dyxyl dot com> ---
Created attachment 15974
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15974&action=edit
Patch to make arange parsing work with signed addresses

The new DWARF indexer parses the .debug_aranges section for line number
information (it looks like previously line number information was read from
some other section).

The problem is that the parser doesn't sign extend the addresses on 32-bit
MIPS, which prevents them from matching during the lookup.  It would work with
addresses less than 2^31.

The attached gdb-signed-aranges.patch fixes the problem with test-gdb.elf at
least.

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[pixel@nobis-crew.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

--- Comment #4 from Nicolas Noble <pixel@nobis-crew.org> ---
I can confirm this patch makes gdb work again properly in my case. I didn't
make the connection with signed pointers, but, yes, it makes sense. I have been
bitten previously by this exact quirk.

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

[Bug symtab/32658] GDB sometimes fails parsing debug information

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32658

--- Comment #5 from Sam James <sam at gentoo dot org> ---
Could you send the patch to the ML please? See
https://sourceware.org/gdb/wiki/ContributionChecklist.

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