mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-12-19 01:19:41 +08:00
21769084e4
With target board unix we get:
...
$ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \
-ex "info function operator\*"
All functions matching regular expression "operator\*":
File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
but with target board cc-with-dwz-m:
...
All functions matching regular expression "operator\*":
File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
The first operator:
...
$ c++filt _ZN3foomlERS_
foo::operator*(foo&)
...
matches address 0x410250 which is defined here in the CU in the exec:
...
<1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
<10f2> DW_AT_specification: <alt 0x93>
<10f6> DW_AT_decl_line : 72
<10f7> DW_AT_decl_column : 7
<10f7> DW_AT_object_pointer: <0x1106>
<10f9> DW_AT_low_pc : 0x410250
<1101> DW_AT_high_pc : 32
<1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<1104> DW_AT_call_all_calls: 1
...
and declared here in the PU in the .dwz file:
...
<2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
<94> DW_AT_external : 1
<94> DW_AT_name : operator*
<98> DW_AT_decl_file : 2
<98> DW_AT_decl_line : 10
<99> DW_AT_decl_column : 9
<9a> DW_AT_linkage_name: _ZN3foomlERS_
<9e> DW_AT_accessibility: 1 (public)
<9e> DW_AT_declaration : 1
<9e> DW_AT_object_pointer: <0xa2>
...
When creating a new symbol for the operator, the DW_AT_decl_file attribute is
looked up, and found to be 2.
The 2 is supposed to be mapped using the PU, which has this file name table:
...
The File Name Table (offset 0x78, lines 3, columns 2):
Entry Dir Name
0 0 <dwz>
1 1 stddef.h
2 2 cplusfuncs.cc
...
Instead, it's mapped using the CU, which has this file name table:
...
The File Name Table (offset 0x34, lines 3, columns 2):
Entry Dir Name
0 1 cplusfuncs.cc
1 1 cplusfuncs.cc
2 2 stddef.h
...
This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where
the same problem happens for two CUs.
Fix this by using the correct file name table.
Add a dwarf assembly test-case for PR25771.
Tested on aarch64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814