commit 5f056fcb3dce947447063f5ab225042177a59722
Author: Tom Tromey <email address hidden>
Date: Fri Feb 24 10:40:16 2023 -0700
Fix crash in inside_main_func
gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.
First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol. So,
while gdb finds the correct name of "main":
(top-gdb) p name
$13 = 0x292e0c0 "rustc_gdb_1031745::main"
It isn't found in the minsyms, because C++ demangling yields:
[99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text rustc_gdb_1031745::main::h5b5be7fe16a97225 zko06yobckx336v
This could perhaps be fixed. I also filed a new PR to suggest
preferring the linkage name of the main program.
Next, the rust compiler emits both a DW_TAG_subprogram and a
DW_TAG_namespace for "main". This happens because the file is named
"main.rs" -- i.e., the bug is specific to the source file name. The
crash also seems to require the nested function inside of 'main', at
least for me. The namespace always is generated, but perhaps this
changes the ordering in the DWARF.
When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function. (I filed a bug about fixing gdb's
symbol tables -- long overdue.)
Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK. This perhaps should have been done
in the first place, anyway.
The master branch has been updated by Tom Tromey <email address hidden>:
https:/ /sourceware. org/git/ gitweb. cgi?p=binutils- gdb.git; h=5f056fcb3dce9 47447063f5ab225 042177a59722
commit 5f056fcb3dce947 447063f5ab22504 2177a59722
Author: Tom Tromey <email address hidden>
Date: Fri Feb 24 10:40:16 2023 -0700
Fix crash in inside_main_func
gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.
First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol. So,
while gdb finds the correct name of "main":
(top-gdb) p name gdb_1031745: :main"
$13 = 0x292e0c0 "rustc_
It isn't found in the minsyms, because C++ demangling yields:
[99] t 0x90c0 _ZN17rustc_ gdb_10317454mai n17h5b5be7fe16a 97225E section .text rustc_gdb_ 1031745: :main:: h5b5be7fe16a972 25 zko06yobckx336v
This could perhaps be fixed. I also filed a new PR to suggest
preferring the linkage name of the main program.
Next, the rust compiler emits both a DW_TAG_subprogram and a TAG_namespace for "main". This happens because the file is named
DW_
"main.rs" -- i.e., the bug is specific to the source file name. The
crash also seems to require the nested function inside of 'main', at
least for me. The namespace always is generated, but perhaps this
changes the ordering in the DWARF.
When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function. (I filed a bug about fixing gdb's
symbol tables -- long overdue.)
Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK. This perhaps should have been done
in the first place, anyway.
Bug: https:/ /sourceware. org/bugzilla/ show_bug. cgi?id= 30158