From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F2C9E3857B8F; Fri, 7 Feb 2025 16:19:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2C9E3857B8F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1738945141; bh=FzUKUFRNRURtVkyxxlF5/meUAUv7IWOL3y2hReQJqfo=; h=From:To:Subject:Date:From; b=Nqc3vtFQbjInGCwCYtmLfmpl7oj70y5tTZAvP8R0yUHDQCguyAuyjL169N843gvRk nuNK7YQmQ+GVDz3FBk7P2jE0jx6fBiNy33OXhzYnbpw3EWcv0EtljEPWLR5gA8Q89X 7aDpP2zfXrZ/Qjw00d9ez2rIavTMvOyskzLS1RqY= From: "pixel@nobis-crew.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/32658] New: GDB sometimes fails parsing debug information Date: Fri, 07 Feb 2025 16:19:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pixel@nobis-crew.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D32658 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=3D15930&action=3Ded= it 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 w= ith 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=3D0x80046240, top=3D0x80046940, size_start=3D8, hypothetical_size=3D1800) at src/alloc.c:131 #2 0x8003ef9c in check_integrity () at src/alloc.c:200 #3 0x8003f73c in psyqo_free (ptr_=3D0x80046948) at src/alloc.c:408 #4 0x80010a68 in free (ptr=3D0x80046948) at lua.cpp:97 #5 0x8002f49c in l_alloc (ud=3D0x0, ptr=3D0x80046948, osize=3D20, nsize=3D= 0) at lauxlib.c:754 #6 0x8001a270 in luaM_realloc_ (L=3D0x80045e90, block=3D0x80046948, osize= =3D20, nsize=3D0) at lmem.c:84 #7 0x8001d714 in luaH_resize (L=3D0x80045e90, t=3D0x800468d8, nasize=3D0, = nhsize=3D2) at ltable.c:331 #8 0x8001d8e0 in rehash (L=3D0x80045e90, t=3D0x800468d8, ek=3D0x80046020) = at ltable.c:356 #9 0x8001db90 in luaH_newkey (L=3D0x80045e90, t=3D0x800468d8, key=3D0x8004= 6020) at ltable.c:413 #10 0x8001e140 in luaH_set (L=3D0x80045e90, t=3D0x800468d8, key=3D0x8004602= 0) at ltable.c:512 #11 0x80026490 in luaX_newstring (ls=3D0x801ffb50, str=3D0x800468b0 "native_callback_loopUso\215\030\004+=E2=96=8C\004'b- = i\004\200(", l=3D20) at llex.c:127 #12 0x80028f20 in llex (ls=3D0x801ffb50, seminfo=3D0x801ffb60) at llex.c:492 #13 0x800290dc in luaX_next (ls=3D0x801ffb50) at llex.c:519 #14 0x8002ea8c in funcstat (ls=3D0x801ffb50, line=3D3) at lparser.c:1470 #15 0x8002ef7c in statement (ls=3D0x801ffb50) at lparser.c:1558 #16 0x8002bc40 in statlist (ls=3D0x801ffb50) at lparser.c:609 #17 0x8002f154 in mainfunc (ls=3D0x801ffb50, fs=3D0x801ffb8c) at lparser.c:= 1610 #18 0x8002f324 in luaY_parser (L=3D0x80045e90, z=3D0x801ffd10, buff=3D0x801= ffca8, dyd=3D0x801ffcb4, name=3D0x80041810 "?", firstchar=3D102) at lparser.c:1630 #19 0x80014ee4 in f_parser (L=3D0x80045e90, ud=3D0x801ffca4) at ldo.c:661 #20 0x800135ac in luaD_rawrunprotected (L=3D0x80045e90, f=3D0x80014d48 , ud=3D0x801ffca4) at ldo.c:141 #21 0x80014c08 in luaD_pcall (L=3D0x80045e90, func=3D0x80014d48 , u=3D0x801ffca4, old_top=3D8, ef=3D0) at ldo.c:613 #22 0x80015094 in luaD_protectedparser (L=3D0x80045e90, z=3D0x801ffd10, name=3D0x80041810 "?", mode=3D0x0) at ldo.c:682 #23 0x80011f5c in lua_load (L=3D0x80045e90, reader=3D0x8002f380 , data=3D0x801ffd48, chunkname=3D0x80041810 "?", mode=3D0x0) at lapi.c:979 #24 0x8002f458 in luaL_loadbufferx (L=3D0x80045e90, buff=3D0x8004442c "function native_callback_init(game, w, h)\nend\nfunction native_callback_loop(dt)\nend\nfunction native_callback_draw()\n=20=20=20 native_draw_rect(0, 10, 10, 20, 20)\nend\n", size=3D160, name=3D0x80041810 "?", mode=3D0x0) at lauxlib.c:519 #25 0x800109a8 in (anonymous namespace)::LuaScene::frame (this=3D0x80045258 <(anonymous namespace)::luaScene>) at lua.cpp:85 #26 0x80033608 in psyqo::Application::run (this=3D0x80044800 <(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 d= ebug 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 w= ant 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=