Tom de Vries [Mon, 18 Jul 2022 11:30:28 +0000 (13:30 +0200)]
[COVER-LETTER] Parallelize process_queue
I. Rationale
When investigating my running example for gdb speed with lto execs (see PR23710):
...
$ gdb -q -batch ./lto/cc1 -ex "b do_rpo_vn"
...
using this patch:
...
@@ -7549,13 +7549,17 @@ maybe_queue_comp_unit (struct dwarf2_cu *dependent_cu,
static void
process_queue (dwarf2_per_objfile *per_objfile)
{
- dwarf_read_debug_printf ("Expanding one or more symtabs of objfile %s ...",
- objfile_name (per_objfile->objfile));
+ if (per_objfile->queue->empty ())
+ return;
/* The queue starts out with one item, but following a DIE reference
may load a new CU, adding it to the end of the queue. */
while (!per_objfile->queue->empty ())
{
+ dwarf_read_debug_printf ("Expanding symtabs of objfile %s, queue size: %zd ...",
+ objfile_name (per_objfile->objfile),
+ per_objfile->queue->size ());
+
dwarf2_queue_item &item = per_objfile->queue->front ();
dwarf2_per_cu_data *per_cu = item.per_cu;
@@ -8522,7 +8526,11 @@ process_imported_unit_die (struct die_info *die, struct dwarf2_cu *cu)
if (die->parent && die->parent->parent == NULL
&& per_cu->unit_type (false) == DW_UT_compile
&& per_cu->lang (false) == language_cplus)
- return;
+ {
+ dwarf_read_debug_printf ("Skipping import of c++ CU at offset %s",
+ sect_offset_str (sect_off));
+ return;
+ }
/* If necessary, add it to the queue and load its DIEs. */
if (maybe_queue_comp_unit (cu, per_cu, per_objfile,
...
and "set debug dwarf-read 1" (dumped into a log file, see V), I noticed:
...
$ grep "Expanding symtabs of" LOG | more
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 1 ...
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 1 ...
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 173 ...
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 172 ...
...
that the queue processed by process_queue can be large, and is processed
sequentially, and I wondered if doing this in parallel might speed things up.
This might also be useful for -readnow, but that might require additional
changes to active this, I haven't checked that yet.
II. Correctness results.
The running example runs without thread sanitizer issues.
Running the testsuite with thread sanitizer revealed issues during
cpexprs-debug-types.exp.
III. Performance results.
I did a performance experiment using:
...
$ for n in $(seq 1 10); do \
time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \
2>&1 \
| grep "real:"; \
done
...
and observed the following results for master:
...
real: 4.09
real: 4.03
real: 4.64
real: 4.04
real: 4.18
real: 4.73
real: 4.63
real: 4.02
real: 4.04
real: 4.03
...
and with this branch:
...
real: 4.04
real: 4.06
real: 3.97
real: 4.59
real: 4.39
real: 4.03
real: 4.03
real: 3.96
real: 3.97
real: 4.54
...
which looks roughtly comparable, so we don't seem to have slowed down the
common case (where we don't excercise process_queue yet).
Then with the running example:
...
$ for n in $(seq 1 10); do \
time gdb -q -batch ./lto/cc1 -ex "b do_rpo_vn" 2>&1 | grep "real:"; \
done
...
with master:
...
real: 4.19
real: 4.40
real: 4.30
real: 4.29
real: 4.20
real: 4.25
real: 4.28
real: 4.22
real: 4.31
real: 4.32
...
and this branch:
...
real: 4.79
real: 4.83
real: 4.81
real: 4.74
real: 4.93
real: 4.92
real: 4.72
real: 4.82
real: 4.77
real: 4.79
...
So, there's a noticable slowdown.
Doing the break after "maint set worker-threads 0" (to force the parallel for
in process_queue to run sequentially) gives us:
...
real: 4.56
real: 4.50
real: 4.57
real: 4.57
real: 4.61
real: 4.58
real: 4.52
real: 4.62
real: 4.52
real: 4.58
...
IV. Analysis.
The slowdown is probably caused by excessive locking. This could be solved by
tracking more things in a thread_local way, but probably at the cost of more
memory.
We could implement a statistics_mutex that dumps the lock/unlock statistics
upon destroying to find out what the problematic locks are (I suspect at least
the die_type ones).
A possibility is that we're not getting the full benefit because we only start
processing in parallel once process_queue is called. A possible fix
would be to have the main thread filling the queue and a dispatcher thread
reading it and dispatching items to worker threads.
Another possibility is that we're not getting the full benefit because we
fairly distribute a number of CUs, but CUs will not be of equal size (this
might hold equally for the cooked index btw). This could be mitigated
somewhat by taking into account the size of the CUs when doing the
distribution. Another solution would be to add a parallel_for_each_dynamic or
some such that dispatches to workers that are idle. [ Presumably the
dispatcher thread mentioned above would behave similarly. ]
[ I've proposed a patch "[gdbsupport] Use task size in parallel_for_each" for
trunk that deals with this issue for the parallel for in
dwarf2_build_psymtabs_hard. Included in this branch before the cover letter. ]
[ A last minute addition "[gdb/symtab] Use task size in parallel for in
process_queue" did not improve the result. ]
V. Dwarf-read log
FTR, full log of gdb output with dwarf-read logging on:
...
[dwarf-read] dwarf2_initialize_objfile: called
[dwarf-read] dwarf2_build_psymtabs_hard: Building psymtabs of objfile cc1 ...
[dwarf-read] read_comp_units_from_section: Reading .debug_info for cc1
[dwarf-read] open_and_init_dwp_file: DWP file not found: cc1.dwp
[dwarf-read] print_tu_stats: Type unit statistics:
[dwarf-read] print_tu_stats: 0 TUs
[dwarf-read] print_tu_stats: 0 uniq abbrev tables
[dwarf-read] print_tu_stats: 0 symtabs from stmt_list entries
[dwarf-read] print_tu_stats: 0 symtab sharers
[dwarf-read] print_tu_stats: 0 type units without a stmt_list
[dwarf-read] print_tu_stats: 0 all_type_units reallocs
[dwarf-read] dwarf2_build_psymtabs_hard: Done building psymtabs of cc1
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 1 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x282e061
[dwarf-read] process_queue: Done expanding CU at offset 0x282e061
[dwarf-read] process_queue: Done expanding symtabs of cc1.
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 1 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x4f726fa
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x18913
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xd9
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x48bb60
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x56019
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x432a1f
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x4c6372
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x27e55eb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x94932
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x17642d
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x261f49
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x52ac2c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x151169
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xd2a8cd
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x279a341
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x256eabe
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x271c86b
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x6a3f89
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x24ad9d6
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x274b291
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x26e630a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x282e06c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x540b58
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x181903c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3f05d53
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xe25133
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x35811ee
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xcc5d11
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1e7e6d1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1e3fbd
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1fb00fe
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x65e263
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x625166
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2a3cb30
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xfa6640
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2d0bdf6
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x22ed46
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x4ef108
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x8d697a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xe50cd2
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x109c04d
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xb42761
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xaa65e8
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x7f222a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1a54bc
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x23c40eb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xd5eccb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xeb4343
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x211992
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xf34af1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x150e087
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xa070aa
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xaf4948
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x922e3c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2628d41
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x229ddf3
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x14c101f
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x709504
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x193586f
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x8c24f9
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x20741b1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x9530c2
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x5f55f9
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x5c2f35
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x58e313
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x19b0475
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xbfb92a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x10f2e0
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xda08e5
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xc90a25
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x16524ce
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x834f38
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2e9352
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x31964b
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x9bd839
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x5a0ea0
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x27cbbf1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1012d7
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2424d46
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xcaaa67
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2017b91
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x6c293d
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x47e745
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x245be5d
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x13f465a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x27840f7
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1f94f6e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x18c12a1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2733a9c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x228970c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x24eed38
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1e085a3
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xc59eeb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x7c4801
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x26b9f5c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x269fd21
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x5db31b
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2687a48
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2478fbe
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2317395
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2657181
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x20d8a89
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1369c6c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x21583cf
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1a76f13
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x849309
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x411fc8
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x260a83d
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x12f73a3
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x899f40
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x195b657
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x25bcc72
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x259688c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3ebb2d5
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3ec48c8
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xc3fc34
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1d36e66
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xee7fc
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x22c669e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3ea4bac
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1ff9d25
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xd0a5eb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x824e4a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xf679ff
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xfe5f20
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x203861e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2a167ce
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xbe8373
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x23ee830
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1efde95
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3028d26
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2e1f51e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x10411d1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x33e777d
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3f0a9ce
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1dc37af
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3ef249e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1751aa5
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1b52685
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x11cc196
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1b3b1e6
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x12eba45
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x414bd
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3f3a624
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2915861
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x248fe5c
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2dadb2
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2113e46
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x321ff16
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3d80b8a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x21879c2
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x19158b7
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1d425c7
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x172a702
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x17709ba
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x335da3
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2c76457
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x12b9fe2
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x38abdf2
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2ee9139
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3d68c0a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1d6e394
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3d49449
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x22278ca
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3ef7e15
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2bf61b9
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x19d1d3a
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xa71c19
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x14eef30
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3e966b0
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xbaa4fb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1e18bd6
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x3ee5f02
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x4082bc
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x46f8cf
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2effdc1
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0xdcd1cb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1270a16
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2243311
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x169070e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1bd41bb
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x39b092
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1ebd919
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x1cb0b5e
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x2381bf5
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x12de1b4
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x220dd2f
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x7436f9
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x36b680
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x765494
[dwarf-read] process_imported_unit_die: Skipping import of c++ CU at offset 0x14061fc
[dwarf-read] process_queue: Done expanding CU at offset 0x4f726fa
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 173 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd7e1b
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd7e1b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 172 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f6f015
[dwarf-read] process_queue: Done expanding CU at offset 0x3f6f015
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 171 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f6a111
[dwarf-read] process_queue: Done expanding CU at offset 0x3f6a111
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 170 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f66c00
[dwarf-read] process_queue: Done expanding CU at offset 0x3f66c00
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 169 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f51880
[dwarf-read] process_queue: Done expanding CU at offset 0x3f51880
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 168 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fcc5a5
[dwarf-read] process_queue: Done expanding CU at offset 0x3fcc5a5
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 167 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd478f
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd478f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 166 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f5eb9c
[dwarf-read] process_queue: Done expanding CU at offset 0x3f5eb9c
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 165 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd916c
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd916c
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 164 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd1973
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd1973
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 163 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd73b7
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd73b7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 162 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fcca75
[dwarf-read] process_queue: Done expanding CU at offset 0x3fcca75
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 161 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd98bd
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd98bd
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 160 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fca0f1
[dwarf-read] process_queue: Done expanding CU at offset 0x3fca0f1
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 159 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd9f5b
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd9f5b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 158 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd1e43
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd1e43
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 157 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fca842
[dwarf-read] process_queue: Done expanding CU at offset 0x3fca842
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 156 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3fd05c2
[dwarf-read] process_queue: Done expanding CU at offset 0x3fd05c2
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 155 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f64557
[dwarf-read] process_queue: Done expanding CU at offset 0x3f64557
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 154 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x52ac21
[dwarf-read] process_queue: Done expanding CU at offset 0x52ac21
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 153 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x27e55e0
[dwarf-read] process_queue: Done expanding CU at offset 0x27e55e0
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 152 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x279a336
[dwarf-read] process_queue: Done expanding CU at offset 0x279a336
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 151 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x27840ec
[dwarf-read] process_queue: Done expanding CU at offset 0x27840ec
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 150 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x274b286
[dwarf-read] process_queue: Done expanding CU at offset 0x274b286
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 149 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x26e62ff
[dwarf-read] process_queue: Done expanding CU at offset 0x26e62ff
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 148 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x26b9f51
[dwarf-read] process_queue: Done expanding CU at offset 0x26b9f51
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 147 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x269fd16
[dwarf-read] process_queue: Done expanding CU at offset 0x269fd16
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 146 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2687a3d
[dwarf-read] process_queue: Done expanding CU at offset 0x2687a3d
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 145 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2657176
[dwarf-read] process_queue: Done expanding CU at offset 0x2657176
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 144 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2596881
[dwarf-read] process_queue: Done expanding CU at offset 0x2596881
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 143 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3ec48bd
[dwarf-read] process_queue: Done expanding CU at offset 0x3ec48bd
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 142 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x6a3f7e
[dwarf-read] process_queue: Done expanding CU at offset 0x6a3f7e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 141 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1819031
[dwarf-read] process_queue: Done expanding CU at offset 0x1819031
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 140 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2733a91
[dwarf-read] process_queue: Done expanding CU at offset 0x2733a91
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 139 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x8c24ee
[dwarf-read] process_queue: Done expanding CU at offset 0x8c24ee
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 138 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3ebb2ca
[dwarf-read] process_queue: Done expanding CU at offset 0x3ebb2ca
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 137 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x18908
[dwarf-read] process_queue: Done expanding CU at offset 0x18908
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 136 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xc3fc29
[dwarf-read] process_queue: Done expanding CU at offset 0xc3fc29
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 135 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x411fbd
[dwarf-read] process_queue: Done expanding CU at offset 0x411fbd
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 134 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x12f7398
[dwarf-read] process_queue: Done expanding CU at offset 0x12f7398
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 133 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xc59ee0
[dwarf-read] process_queue: Done expanding CU at offset 0xc59ee0
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 132 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1e7e6c6
[dwarf-read] process_queue: Done expanding CU at offset 0x1e7e6c6
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 131 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x271c860
[dwarf-read] process_queue: Done expanding CU at offset 0x271c860
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 130 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xcaaa5c
[dwarf-read] process_queue: Done expanding CU at offset 0xcaaa5c
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 129 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2a3cb25
[dwarf-read] process_queue: Done expanding CU at offset 0x2a3cb25
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 128 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x5600e
[dwarf-read] process_queue: Done expanding CU at offset 0x5600e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 127 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3ea4ba1
[dwarf-read] process_queue: Done expanding CU at offset 0x3ea4ba1
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 126 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x540b4d
[dwarf-read] process_queue: Done expanding CU at offset 0x540b4d
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 125 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x195b64c
[dwarf-read] process_queue: Done expanding CU at offset 0x195b64c
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 124 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xf34ae6
[dwarf-read] process_queue: Done expanding CU at offset 0xf34ae6
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 123 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x58e308
[dwarf-read] process_queue: Done expanding CU at offset 0x58e308
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 122 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x5db310
[dwarf-read] process_queue: Done expanding CU at offset 0x5db310
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 121 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x5f55ee
[dwarf-read] process_queue: Done expanding CU at offset 0x5f55ee
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 120 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2d0bdeb
[dwarf-read] process_queue: Done expanding CU at offset 0x2d0bdeb
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 119 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x33e7772
[dwarf-read] process_queue: Done expanding CU at offset 0x33e7772
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 118 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2289701
[dwarf-read] process_queue: Done expanding CU at offset 0x2289701
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 117 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x211987
[dwarf-read] process_queue: Done expanding CU at offset 0x211987
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 116 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1d36e5b
[dwarf-read] process_queue: Done expanding CU at offset 0x1d36e5b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 115 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x220dd24
[dwarf-read] process_queue: Done expanding CU at offset 0x220dd24
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 114 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x245be52
[dwarf-read] process_queue: Done expanding CU at offset 0x245be52
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 113 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xc90a1a
[dwarf-read] process_queue: Done expanding CU at offset 0xc90a1a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 112 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1f94f63
[dwarf-read] process_queue: Done expanding CU at offset 0x1f94f63
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 111 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x22ed3b
[dwarf-read] process_queue: Done expanding CU at offset 0x22ed3b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 110 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x23ee825
[dwarf-read] process_queue: Done expanding CU at offset 0x23ee825
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 109 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x20741a6
[dwarf-read] process_queue: Done expanding CU at offset 0x20741a6
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 108 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x47e73a
[dwarf-read] process_queue: Done expanding CU at offset 0x47e73a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 107 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1fb00f3
[dwarf-read] process_queue: Done expanding CU at offset 0x1fb00f3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 106 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1dc37a4
[dwarf-read] process_queue: Done expanding CU at offset 0x1dc37a4
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 105 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xb42756
[dwarf-read] process_queue: Done expanding CU at offset 0xb42756
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 104 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x48bb55
[dwarf-read] process_queue: Done expanding CU at offset 0x48bb55
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 103 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x94927
[dwarf-read] process_queue: Done expanding CU at offset 0x94927
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 102 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x321ff0b
[dwarf-read] process_queue: Done expanding CU at offset 0x321ff0b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 101 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x18c1296
[dwarf-read] process_queue: Done expanding CU at offset 0x18c1296
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 100 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2038613
[dwarf-read] process_queue: Done expanding CU at offset 0x2038613
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 99 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xd0a5e0
[dwarf-read] process_queue: Done expanding CU at offset 0xd0a5e0
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 98 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xcc5d06
[dwarf-read] process_queue: Done expanding CU at offset 0xcc5d06
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 97 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x19b046a
[dwarf-read] process_queue: Done expanding CU at offset 0x19b046a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 96 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x65e258
[dwarf-read] process_queue: Done expanding CU at offset 0x65e258
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 95 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2a167c3
[dwarf-read] process_queue: Done expanding CU at offset 0x2a167c3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 94 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x231738a
[dwarf-read] process_queue: Done expanding CU at offset 0x231738a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 93 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2c7644c
[dwarf-read] process_queue: Done expanding CU at offset 0x2c7644c
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 92 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x10f2d5
[dwarf-read] process_queue: Done expanding CU at offset 0x10f2d5
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 91 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x12de1a9
[dwarf-read] process_queue: Done expanding CU at offset 0x12de1a9
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 90 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2e9347
[dwarf-read] process_queue: Done expanding CU at offset 0x2e9347
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 89 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3ef2493
[dwarf-read] process_queue: Done expanding CU at offset 0x3ef2493
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 88 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x432a14
[dwarf-read] process_queue: Done expanding CU at offset 0x432a14
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 87 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x39b087
[dwarf-read] process_queue: Done expanding CU at offset 0x39b087
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 86 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x21583c4
[dwarf-read] process_queue: Done expanding CU at offset 0x21583c4
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 85 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x248fe51
[dwarf-read] process_queue: Done expanding CU at offset 0x248fe51
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 84 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2915856
[dwarf-read] process_queue: Done expanding CU at offset 0x2915856
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 83 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2628d36
[dwarf-read] process_queue: Done expanding CU at offset 0x2628d36
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 82 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x260a832
[dwarf-read] process_queue: Done expanding CU at offset 0x260a832
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 81 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2478fb3
[dwarf-read] process_queue: Done expanding CU at offset 0x2478fb3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 80 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x5a0e95
[dwarf-read] process_queue: Done expanding CU at offset 0x5a0e95
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 79 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xda08da
[dwarf-read] process_queue: Done expanding CU at offset 0xda08da
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 78 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x16524c3
[dwarf-read] process_queue: Done expanding CU at offset 0x16524c3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 77 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x22c6693
[dwarf-read] process_queue: Done expanding CU at offset 0x22c6693
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 76 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x35811e3
[dwarf-read] process_queue: Done expanding CU at offset 0x35811e3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 75 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x172a6f7
[dwarf-read] process_queue: Done expanding CU at offset 0x172a6f7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 74 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x20d8a7e
[dwarf-read] process_queue: Done expanding CU at offset 0x20d8a7e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 73 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x25bcc67
[dwarf-read] process_queue: Done expanding CU at offset 0x25bcc67
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 72 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x150e07c
[dwarf-read] process_queue: Done expanding CU at offset 0x150e07c
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 71 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xaf493d
[dwarf-read] process_queue: Done expanding CU at offset 0xaf493d
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 70 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x27cbbe6
[dwarf-read] process_queue: Done expanding CU at offset 0x27cbbe6
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 69 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x9530b7
[dwarf-read] process_queue: Done expanding CU at offset 0x9530b7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 68 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x7c47f6
[dwarf-read] process_queue: Done expanding CU at offset 0x7c47f6
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 67 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xfa6635
[dwarf-read] process_queue: Done expanding CU at offset 0xfa6635
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 66 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x13f464f
[dwarf-read] process_queue: Done expanding CU at offset 0x13f464f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 65 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x9bd82e
[dwarf-read] process_queue: Done expanding CU at offset 0x9bd82e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 64 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x24ad9cb
[dwarf-read] process_queue: Done expanding CU at offset 0x24ad9cb
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 63 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x256eab3
[dwarf-read] process_queue: Done expanding CU at offset 0x256eab3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 62 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x24eed2d
[dwarf-read] process_queue: Done expanding CU at offset 0x24eed2d
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 61 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1ff9d1a
[dwarf-read] process_queue: Done expanding CU at offset 0x1ff9d1a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 60 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x6c2932
[dwarf-read] process_queue: Done expanding CU at offset 0x6c2932
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 59 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xf679f4
[dwarf-read] process_queue: Done expanding CU at offset 0xf679f4
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 58 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xe50cc7
[dwarf-read] process_queue: Done expanding CU at offset 0xe50cc7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 57 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1a54b1
[dwarf-read] process_queue: Done expanding CU at offset 0x1a54b1
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 56 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2ed3119
[dwarf-read] process_queue: Done expanding CU at offset 0x2ed3119
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 55 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x319640
[dwarf-read] process_queue: Done expanding CU at offset 0x319640
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 54 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x261f3e
[dwarf-read] process_queue: Done expanding CU at offset 0x261f3e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 53 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x229dde8
[dwarf-read] process_queue: Done expanding CU at offset 0x229dde8
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 52 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x4ef0fd
[dwarf-read] process_queue: Done expanding CU at offset 0x4ef0fd
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 51 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x4c6367
[dwarf-read] process_queue: Done expanding CU at offset 0x4c6367
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 50 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2e1f513
[dwarf-read] process_queue: Done expanding CU at offset 0x2e1f513
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 49 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xd5ecc0
[dwarf-read] process_queue: Done expanding CU at offset 0xd5ecc0
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 48 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xd2a8c2
[dwarf-read] process_queue: Done expanding CU at offset 0xd2a8c2
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 47 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xaa65dd
[dwarf-read] process_queue: Done expanding CU at offset 0xaa65dd
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 46 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xeb4338
[dwarf-read] process_queue: Done expanding CU at offset 0xeb4338
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 45 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x7f221f
[dwarf-read] process_queue: Done expanding CU at offset 0x7f221f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 44 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x109c042
[dwarf-read] process_queue: Done expanding CU at offset 0x109c042
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 43 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xa71c0e
[dwarf-read] process_queue: Done expanding CU at offset 0xa71c0e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 42 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x922e31
[dwarf-read] process_queue: Done expanding CU at offset 0x922e31
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 41 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x23c40e0
[dwarf-read] process_queue: Done expanding CU at offset 0x23c40e0
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 40 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x8d696f
[dwarf-read] process_queue: Done expanding CU at offset 0x8d696f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 39 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3028d1b
[dwarf-read] process_queue: Done expanding CU at offset 0x3028d1b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 38 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2424d3b
[dwarf-read] process_queue: Done expanding CU at offset 0x2424d3b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 37 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x834f2d
[dwarf-read] process_queue: Done expanding CU at offset 0x834f2d
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 36 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2381bea
[dwarf-read] process_queue: Done expanding CU at offset 0x2381bea
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 35 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1b3b1db
[dwarf-read] process_queue: Done expanding CU at offset 0x1b3b1db
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 34 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1b5267a
[dwarf-read] process_queue: Done expanding CU at offset 0x1b5267a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 33 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f3a619
[dwarf-read] process_queue: Done expanding CU at offset 0x3f3a619
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 32 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x19158ac
[dwarf-read] process_queue: Done expanding CU at offset 0x19158ac
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 31 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1d425bc
[dwarf-read] process_queue: Done expanding CU at offset 0x1d425bc
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 30 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1e08598
[dwarf-read] process_queue: Done expanding CU at offset 0x1e08598
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 29 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x335d98
[dwarf-read] process_queue: Done expanding CU at offset 0x335d98
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 28 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3f0a9c3
[dwarf-read] process_queue: Done expanding CU at offset 0x3f0a9c3
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 27 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1751a9a
[dwarf-read] process_queue: Done expanding CU at offset 0x1751a9a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 26 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xbfb91f
[dwarf-read] process_queue: Done expanding CU at offset 0xbfb91f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 25 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x824e3f
[dwarf-read] process_queue: Done expanding CU at offset 0x824e3f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 24 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x36b675
[dwarf-read] process_queue: Done expanding CU at offset 0x36b675
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 23 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x17709af
[dwarf-read] process_queue: Done expanding CU at offset 0x17709af
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 22 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x5c2f2a
[dwarf-read] process_queue: Done expanding CU at offset 0x5c2f2a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 21 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2113e3b
[dwarf-read] process_queue: Done expanding CU at offset 0x2113e3b
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 20 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x16f9378
[dwarf-read] process_queue: Done expanding CU at offset 0x16f9378
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 19 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3d68bff
[dwarf-read] process_queue: Done expanding CU at offset 0x3d68bff
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 18 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2ee912e
[dwarf-read] process_queue: Done expanding CU at offset 0x2ee912e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 17 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1d6e389
[dwarf-read] process_queue: Done expanding CU at offset 0x1d6e389
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 16 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x899f35
[dwarf-read] process_queue: Done expanding CU at offset 0x899f35
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 15 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3d4943e
[dwarf-read] process_queue: Done expanding CU at offset 0x3d4943e
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 14 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x14061f1
[dwarf-read] process_queue: Done expanding CU at offset 0x14061f1
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 13 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xfe5f15
[dwarf-read] process_queue: Done expanding CU at offset 0xfe5f15
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 12 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1935864
[dwarf-read] process_queue: Done expanding CU at offset 0x1935864
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 11 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x21879b7
[dwarf-read] process_queue: Done expanding CU at offset 0x21879b7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 10 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3d80b7f
[dwarf-read] process_queue: Done expanding CU at offset 0x3d80b7f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 9 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1369c61
[dwarf-read] process_queue: Done expanding CU at offset 0x1369c61
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 8 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1a76f08
[dwarf-read] process_queue: Done expanding CU at offset 0x1a76f08
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 7 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x7094f9
[dwarf-read] process_queue: Done expanding CU at offset 0x7094f9
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 6 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x12b9fd7
[dwarf-read] process_queue: Done expanding CU at offset 0x12b9fd7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 5 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x38abde7
[dwarf-read] process_queue: Done expanding CU at offset 0x38abde7
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 4 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x19d1d2f
[dwarf-read] process_queue: Done expanding CU at offset 0x19d1d2f
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 3 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3ef7e0a
[dwarf-read] process_queue: Done expanding CU at offset 0x3ef7e0a
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 2 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2bf61ae
[dwarf-read] process_queue: Done expanding CU at offset 0x2bf61ae
[dwarf-read] process_queue: Expanding symtabs of objfile cc1, queue size: 1 ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x765489
[dwarf-read] process_queue: Done expanding CU at offset 0x765489
[dwarf-read] process_queue: Done expanding symtabs of cc1.
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
...
Tom de Vries [Mon, 18 Jul 2022 17:31:19 +0000 (19:31 +0200)]
[gdbsupport] Use task size in parallel_for_each
Ensuring a fair distribution over the worker threads and main thread in terms
of number of CUs might not be the most efficient way, given that CUs can vary
in size.
Fix this by:
- adding a task_size_ptr parameter to parallel_for_each,
defaulting to nullptr,
- using per_cu->get_length () as the task size in the parallel_for_each
in dwarf2_build_psymtabs_hard, and
- using the task size in parallel_for_each to distribute similarly-sized tasks
to the threads.
I've used this experiment to verify the performance impact:
...
$ for n in $(seq 1 10); do \
time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \
2>&1 \
| grep "real:"; \
done
...
and without the patch got:
...
real: 4.71
real: 4.88
real: 4.29
real: 4.30
real: 4.65
real: 4.27
real: 4.27
real: 4.27
real: 4.75
real: 4.41
...
and with the patch:
...
real: 3.68
real: 3.81
real: 3.80
real: 3.68
real: 3.75
real: 3.69
real: 3.69
real: 3.74
real: 3.67
real: 3.74
...
so that seems a reasonable improvement.
With parallel_for_each_debug set to true, we get some more detail about
the difference in behaviour. Without the patch we have:
...
Parallel for: n_elements: 2818
Parallel for: minimum elements per thread: 1
Parallel for: elts_per_thread: 704
Parallel for: elements on worker thread 0 : 705
Parallel for: elements on worker thread 1 : 705
Parallel for: elements on worker thread 2 : 704
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 704
...
and with the patch:
...
Parallel for: n_elements: 2818
Parallel for: total_size: 1483674865
Parallel for: size_per_thread: 370918716
Parallel for: elements on worker thread 0 : 752 (size: 371811790)
Parallel for: elements on worker thread 1 : 360 (size: 371509370)
Parallel for: elements on worker thread 2 : 1130 (size: 372681710)
Parallel for: elements on worker thread 3 : 0 (size: 0)
Parallel for: elements on main thread : 576 (size: 367671995)
...
Tom de Vries [Thu, 21 Jul 2022 12:04:41 +0000 (14:04 +0200)]
[gdb/python] Fix python selftest with python 3.11
With python 3.11 I noticed:
...
$ gdb -q -batch -ex "maint selftest python"
Running selftest python.
Self test failed: self-test failed at gdb/python/python.c:2246
Ran 1 unit tests, 1 failed
...
In more detail:
...
(gdb) p output
$5 = "Traceback (most recent call last):\n File \"<string>\", line 0, \
in <module>\nKeyboardInterrupt\n"
(gdb) p ref_output
$6 = "Traceback (most recent call last):\n File \"<string>\", line 1, \
in <module>\nKeyboardInterrupt\n"
...
Fix this by also allowing line number 0.
Tested on x86_64-linux.
This should hopefully fix buildbot builder gdb-rawhide-x86_64.
Tom de Vries [Thu, 21 Jul 2022 11:05:39 +0000 (13:05 +0200)]
[gdb/symtab] Fix bad compile unit index complaint
I noticed this code in dw2_debug_names_iterator::next:
...
case DW_IDX_compile_unit:
/* Don't crash on bad data. */
if (ull >= per_bfd->all_comp_units.size ())
{
complaint (_(".debug_names entry has bad CU index %s"
" [in module %s]"),
pulongest (ull),
objfile_name (objfile));
continue;
}
per_cu = per_bfd->get_cu (ull);
break;
...
This code used to DTRT, before we started keeping both CUs and TUs in
all_comp_units.
Fix by using "per_bfd->all_comp_units.size () - per_bfd->tu_stats.nr_tus"
instead.
It's hard to produce a test-case for this, but let's try at least to trigger
the complaint somehow. We start out by creating an exec with .debug_types and
.debug_names:
...
$ gcc -g ~/hello.c -fdebug-types-section
$ gdb-add-index -dwarf-5 a.out
...
and verify that we don't see any complaints:
...
$ gdb -q -batch -iex "set complaints 100" ./a.out
...
We look at the CU and TU table using readelf -w and conclude that we have
nr_cus == 6 and nr_tus == 1.
Now override ull in dw2_debug_names_iterator::next for the DW_IDX_compile_unit
case to 6, and we have:
...
$ gdb -q -batch -iex "set complaints 100" ./a.out
During symbol reading: .debug_names entry has bad CU index 6 [in module a.out]
...
After this, it still crashes because this code in
dw2_debug_names_iterator::next:
...
/* Skip if already read in. */
if (m_per_objfile->symtab_set_p (per_cu))
goto again;
...
is called with per_cu == nullptr.
Fix this by skipping the entry if per_cu == nullptr.
Now revert the fix and observe that the complaint disappears, so we've
confirmed that the fix is required.
A somewhat similar issue for .gdb_index in dw2_symtab_iter_next has been filed
as PR29367.
Tested on x86_64-linux, with native and target board cc-with-debug-names.
Jan Beulich [Thu, 21 Jul 2022 10:32:25 +0000 (12:32 +0200)]
x86: replace wrong attributes on VCVTDQ2PH{X,Y}
A standalone (without SAE) StaticRounding attribute is meaningless, and
indeed all other similar insns have ATTSyntax there instead. I can only
assume this was some strange copy-and-paste mistake.
Jan Beulich [Thu, 21 Jul 2022 10:32:04 +0000 (12:32 +0200)]
x86/Intel: correct AVX512F scatter insn element sizes
I clearly screwed up in 6ff00b5e12e7 ("x86/Intel: correct permitted
operand sizes for AVX512 scatter/gather") giving all AVX512F scatter
insns Dword element size. Update testcases (also their gather parts),
utilizing that there previously were two identical lines each (for no
apparent reason).
Alan Modra [Thu, 21 Jul 2022 00:26:15 +0000 (09:56 +0930)]
PR29370, infinite loop in display_debug_abbrev
The PR29370 testcase is a fuzzed object file with multiple
.trace_abbrev sections. Multiple .trace_abbrev or .debug_abbrev
sections are not a violation of the DWARF standard. The DWARF5
standard even gives an example of multiple .debug_abbrev sections
contained in groups. Caching and lookup of processed abbrevs thus
needs to be done by section and offset rather than base and offset.
(Why base anyway?) Or, since section contents are kept, by a pointer
into the contents.
PR 29370
* dwarf.c (struct abbrev_list): Replace abbrev_base and
abbrev_offset with raw field.
(find_abbrev_list_by_abbrev_offset): Delete.
(find_abbrev_list_by_raw_abbrev): New function.
(process_abbrev_set): Set list->raw and list->next.
(find_and_process_abbrev_set): Replace abbrev list lookup with
new function. Don't set list abbrev_base, abbrev_offset or next.
Alan Modra [Wed, 20 Jul 2022 23:08:14 +0000 (08:38 +0930)]
binutils/dwarf.c: abbrev caching
I'm inclined to think that abbrev caching is counter-productive. The
time taken to search the list of abbrevs converted to internal form is
non-zero, and it's easy to decode the raw abbrevs. It's especially
silly to cache empty lists of decoded abbrevs (happens with zero
padding in .debug_abbrev), or abbrevs as they are displayed when there
is no further use of those abbrevs. This patch stops caching in those
cases.
* dwarf.c (record_abbrev_list_for_cu): Add free_list param.
Put abbrevs on abbrev_lists here.
(new_abbrev_list): Delete function.
(process_abbrev_set): Return newly allocated list. Move
abbrev base, offset and size checking to..
(find_and_process_abbrev_set): ..here, new function. Handle
lookup of cached abbrevs here, and calculate start and end
for process_abbrev_set. Return free_list if newly alloc'd.
(process_debug_info): Consolidate cached list lookup, new list
alloc and processing into find_and_process_abbrev_set call.
Free list when not cached.
(display_debug_abbrev): Similarly.
Alan Modra [Wed, 20 Jul 2022 08:58:50 +0000 (18:28 +0930)]
miscellaneous dwarf.c tidies
* dwarf.c: Leading and trailing whitespace fixes.
(free_abbrev_list): New function.
(free_all_abbrevs): Use the above. Free cu_abbrev_map here too.
(process_abbrev_set): Print actual section name on error.
(get_type_abbrev_from_form): Add overflow check.
(free_debug_memory): Don't free cu_abbrev_map here..
(process_debug_info): ..or here. Warn on another case of not
finding a neeeded abbrev.
Alan Modra [Thu, 21 Jul 2022 04:01:51 +0000 (13:31 +0930)]
PowerPC64: fix build error on 32-bit hosts
elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=]
11673 | fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset);
| ~~~^ ~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | bfd_vma {aka long long unsigned int}
| long unsigned int
| %#llx
Kevin Buettner [Thu, 30 Jun 2022 22:40:29 +0000 (15:40 -0700)]
Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramName
Python 3.11 deprecates PySys_SetPath and Py_SetProgramName. The
PyConfig API replaces these and other functions. This commit uses the
PyConfig API to provide equivalent functionality while also preserving
support for older versions of Python, i.e. those before Python 3.8.
A beta version of Python 3.11 is available in Fedora Rawhide. Both
Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used
Python 3.9. I've tested these changes on Fedora 34, Fedora 36, and
rawhide, though complete testing was not possible on rawhide due to
a kernel bug. That being the case, I decided to enable the newer
PyConfig API by testing PY_VERSION_HEX against 0x030a0000. This
corresponds to Python 3.10.
We could try to use the PyConfig API for Python versions as early as 3.8,
but I'm reluctant to do this as there may have been PyConfig related
bugs in earlier versions which have since been fixed. Recent linux
distributions should have support for Python 3.10. This should be
more than adequate for testing the new Python initialization code in
GDB.
Information about the PyConfig API as well as the motivation behind
deprecating the old interface can be found at these links:
The v2 commit also addresses several problems that Simon found in
the v1 version.
In v1, I had used Py_DontWriteBytecodeFlag in the new initialization
code, but Simon pointed out that this global configuration variable
will be deprecated in Python 3.12. This version of the patch no longer
uses Py_DontWriteBytecodeFlag in the new initialization code.
Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag
will no longer be used when building GDB against Python 3.10 or higher.
While it's true that both of these global configuration variables are
deprecated in Python 3.12, it makes sense to disable their use for
gdb builds against 3.10 and higher since those are the versions for
which the PyConfig API is now being used by GDB. (The PyConfig API
includes different mechanisms for making the same settings afforded
by use of the soon-to-be deprecated global configuration variables.)
Simon also noted that PyConfig_Clear() would not have be called for
one of the failure paths. I've fixed that problem and also made the
rest of the "bail out" code more direct. In particular,
PyConfig_Clear() will always be called, both for success and failure.
The v3 patch addresses some rebase conflicts related to module
initialization . Commit 3acd9a692dd ("Make 'import gdb.events' work")
uses PyImport_ExtendInittab instead of PyImport_AppendInittab. That
commit also initializes a struct for each module to import. Both the
initialization and the call to were moved ahead of the ifdefs to avoid
having to replicate (at least some of) the code three times in various
portions of the ifdefs.
gdb/value.c: add several headers to the include list
Building GDB currently fails to build with libc++, because libc++ is
stricter about which headers "leak" entities they're not guaranteed
to support. The following headers have been added:
* `<iterator>`, to support `std::back_inserter`
* `<utility>`, to support `std::move` and `std::swap`
* `<vector>`, to support `std::vector`
Pedro Alves [Mon, 18 Jul 2022 17:22:15 +0000 (18:22 +0100)]
Don't stop all threads prematurely after first step of "step N"
In all-stop mode, when the target is itself in non-stop mode (like
GNU/Linux), if you use the "step N" (or "stepi/next/nexti N") to step
a thread a number of times:
(gdb) help step
step, s
Step program until it reaches a different source line.
Usage: step [N]
Argument N means step N times (or till program stops for another reason).
... GDB prematurely stops all threads after the first step, and
doesn't re-resume them for the subsequent N-1 steps. It's as if for
the 2nd and subsequent steps, the command was running with
scheduler-locking enabled.
This can be observed with the testcase added by this commit, which
looks like this:
/* We run to this line below, and then issue "next 3". That should
step over the 3 lines below and land on the return statement. If
GDB prematurely stops the thread_func thread after the first of
the 3 nexts (and never resumes it again), then the join won't
ever return. */
pthread_create (&thread, NULL, thread_func, NULL); /* set break here */
pthread_barrier_wait (&barrier);
pthread_join (thread, NULL);
return 0;
}
The test hangs and times out without the GDB fix:
(gdb) next 3
[New Thread 0x7ffff7d89700 (LWP 525772)]
FAIL: gdb.threads/step-N-all-progress.exp: non-stop=off: target-non-stop=on: next 3 (timeout)
The problem is a core gdb bug.
When you do "step/stepi/next/nexti N", GDB internally creates a
thread_fsm object and associates it with the stepping thread. For the
stepping commands, the FSM's class is step_command_fsm. That object
is what keeps track of how many steps are left to make. When one step
finishes, handle_inferior_event calls stop_waiting and returns, and
then fetch_inferior_event calls the "should_stop" method of the event
thread's FSM. The implementation of that method decrements the
steps-left counter. If the counter is 0, it returns true and we
proceed to presenting the stop to the user. If it isn't 0 yet, then
the method returns false, indicating to fetch_inferior_event to "keep
going".
Focusing now on when the first step finishes -- we're in "all-stop"
mode, with the target in non-stop mode. When a step finishes,
handle_inferior_event calls stop_waiting, which itself calls
stop_all_threads to stop everything. I.e., after the first step
completes, all threads are stopped, before handle_inferior_event
returns. And after that, now in fetch_inferior_event, we consult the
thread's thread_fsm::should_stop, which as we've seen, for the first
step returns false -- i.e., we need to keep_going for another step.
However, since the target is in non-stop mode, keep_going resumes
_only_ the current thread. All the other threads remain stopped,
inadvertently.
If the target is in non-stop mode, we don't actually need to stop all
threads right after each step finishes, and then re-resume them again.
We can instead defer stopping all threads until all the steps are
completed.
So fix this by delaying the stopping of all threads until after we
called the FSM's "should_stop" method. I.e., move it from
stop_waiting, to handle_inferior_events's callers,
fetch_inferior_event and wait_for_inferior.
New test included. Tested on x86-64 GNU/Linux native and gdbserver.
Assuming GMSD is a special operand, marked as O_md1, the code:
.set VREG, GMSD
.set REG, VREG
extsw REG, 2
...fails upon attempts to resolve the value of the symbol. This happens
since machine-dependent values are not handled in the giant op switch.
We introduce a custom md_resolve_symbol macro; the ports can use this
macro to customize the behavior when resolve_symbol_value hits O_md
operand.
H.J. Lu [Tue, 19 Jul 2022 01:24:26 +0000 (18:24 -0700)]
x86: Disallow invalid relocations against protected symbols
Since glibc 2.36 will issue warnings for copy relocation against
protected symbols and non-canonical reference to canonical protected
functions, change the linker to always disallow such relocations.
bfd/
* elf32-i386.c (elf_i386_scan_relocs): Remove check for
elf_has_indirect_extern_access.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
(elf_x86_64_relocate_section): Remove check for
elf_has_no_copy_on_protected.
* elfxx-x86.c (elf_x86_allocate_dynrelocs): Check for building
executable instead of elf_has_no_copy_on_protected.
(_bfd_x86_elf_adjust_dynamic_symbol): Disallow copy relocation
against non-copyable protected symbol.
* elfxx-x86.h (SYMBOL_NO_COPYRELOC): Remove check for
elf_has_no_copy_on_protected.
ld/
* testsuite/ld-i386/i386.exp: Expect linker error for PR ld/17709
test.
* testsuite/ld-i386/pr17709.rd: Removed.
* testsuite/ld-i386/pr17709.err: New file.
* testsuite/ld-x86-64/pr17709.rd: Removed.
* testsuite/ld-x86-64/pr17709.err: New file.
* testsuite/ld-x86-64/pr28875-func.err: Updated.
* testsuite/ld-x86-64/x86-64.exp: Expect linker error for PR
ld/17709 test. Add tests for function pointer against protected
function.
Fangrui Song [Sat, 25 Jun 2022 17:44:26 +0000 (10:44 -0700)]
x86: Make protected symbols local for -shared
Call _bfd_elf_symbol_refs_local_p with local_protected==true. This has
2 noticeable effects for -shared:
* GOT-generating relocations referencing a protected data symbol no
longer lead to a GLOB_DAT (similar to a hidden symbol).
* Direct access relocations (e.g. R_X86_64_PC32) no longer has the
confusing diagnostic below.
Note: if some code tries to use direct access relocations to take the
address of foo, the pointer equality will break, but the error should be
reported on the executable link, not on the innocent shared object link.
glibc 2.36 will give a warning at relocation resolving time.
With this change, `#define elf_backend_extern_protected_data 1` is no
longer effective. Just remove it.
Remove the test "Run protected-func-1 without PIE" since -fno-pic
address taken operation in the executable doesn't work with protected
symbol in a shared object by default. Similarly, remove
protected-data-1a and protected-data-1b. protected-data-1b can be made
working by removing HAVE_LD_PIE_COPYRELOC from GCC
(https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html).
Luis Machado [Thu, 31 Mar 2022 10:42:35 +0000 (11:42 +0100)]
[AArch64] MTE corefile support
Teach GDB how to dump memory tags for AArch64 when using the gcore command
and how to read memory tag data back from a core file generated by GDB
(via gcore) or by the Linux kernel.
The format is documented in the Linux Kernel documentation [1].
Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
of those segments when reading the core file back.
To save a little bit of space, given MTE tags only take 4 bits, the memory tags
are stored packed as 2 tags per byte.
When reading the data back, the tags are unpacked.
I've added a new testcase to exercise the feature.
Build-tested with --enable-targets=all and regression tested on aarch64-linux
Ubuntu 20.04.
Luis Machado [Tue, 28 Jun 2022 11:57:34 +0000 (12:57 +0100)]
[AArch64] Support AArch64 MTE memory tag dumps in core files
The Linux kernel can dump memory tag segments to a core file, one segment
per mapped range. The format and documentation can be found in the Linux
kernel tree [1].
The following patch adjusts bfd and binutils so they can handle this new
segment type and display it accordingly. It also adds code required so GDB
can properly read/dump core file data containing memory tags.
Upon reading, each segment that contains memory tags gets mapped to a
section named "memtag". These sections will be used by GDB to lookup the tag
data. There can be multiple such sections with the same name, and they are not
numbered to simplify GDB's handling and lookup.
There is another patch for GDB that enables both reading
and dumping of memory tag segments.
Luis Machado [Tue, 28 Jun 2022 13:08:46 +0000 (14:08 +0100)]
[AArch64] Fix testcase compilation failure
Newer distros carry newer headers that contains MTE definitions. Account
for that fact in the MTE testcases (gdb.arch/aarch64-mte.exp) and define
constants conditionally to prevent compilation failures.
H.J. Lu [Mon, 18 Jul 2022 18:44:32 +0000 (11:44 -0700)]
x86: Properly check invalid relocation against protected symbol
Only check invalid relocation against protected symbol defined in shared
object.
bfd/
PR ld/29377
* elf32-i386.c (elf_i386_scan_relocs): Only check invalid
relocation against protected symbol defined in shared object.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
ld/
PR ld/29377
* testsuite/ld-elf/linux-x86.exp: Run PR ld/29377 tests.
* testsuite/ld-elf/pr29377a.c: New file.
* testsuite/ld-elf/pr29377b.c: Likewise.
Tom Tromey [Mon, 20 Jun 2022 17:30:04 +0000 (11:30 -0600)]
Add gdb.free_objfile event registry
Currently, Python code can use event registries to detect when gdb
loads a new objfile, and when gdb clears the objfile list. However,
there's no way to detect the removal of an objfile, say when the
inferior calls dlclose.
This patch adds a gdb.free_objfile event registry and arranges for an
event to be emitted in this case.
Tom Tromey [Fri, 17 Jun 2022 13:41:37 +0000 (07:41 -0600)]
Remove array typedef assumption for Ada
Currently the Ada code assumes that it can distinguish between a
multi-dimensional array and an array of arrays by looking for an
intervening typedef -- that is, for an array of arrays, there will be
a typedef wrapping the innermost array type.
A recent compiler change removes this typedef, which causes a gdb
failure in the internal AdaCore test suite.
This patch handles this case by checking whether the array type in
question has a name.
Tom Tromey [Thu, 23 Jun 2022 17:05:39 +0000 (11:05 -0600)]
Remove ui_register_input_event_handler
This patch removes ui_register_input_event_handler and
ui_unregister_input_event_handler, replacing them with methods on
'ui'. It also changes gdb to use these methods everywhere, rather
than sometimes reaching in to the ui to manage the file descriptor
directly.
opcodes/arc: Implement style support in the disassembler
Update the ARC disassembler to supply style information to the
disassembler output. The output formatting remains unchanged.
opcodes/ChangeLog:
* disassemble.c (disassemble_init_for_target): Set
created_styled_output for ARC based targets.
* arc-dis.c (find_format_from_table): Use fprintf_styled_ftype
instead of fprintf_ftype throughout.
(find_format): Likewise.
(print_flags): Likewise.
(print_insn_arc): Likewise.
Tom de Vries [Mon, 18 Jul 2022 10:48:39 +0000 (12:48 +0200)]
[gdb/testsuite] Remove duplicate of supports_gnuc
In commit 9d9dd861e98 ("[gdb/testsuite] Fix regression in
step-indirect-call-thunk.exp with gcc 7") I accidentally committed a duplicate
of supports_gnuc, which caused:
...
DUPLICATE: gdb.base/gdb-caching-proc.exp: supports_gnuc: consistency
...
Andrew Burgess [Mon, 4 Jul 2022 15:40:05 +0000 (16:40 +0100)]
gdb/python: look for python, then python 3 at configure time
It is possible that a system might have a python3 executable, but no
python executable. For example, on my Fedora system the python2
package provides /usr/bin/python2, the python3 package provides
/usr/bin/python3, and the python-unversioned-command package provides
/usr/bin/python, which picks between python2 and python3.
It is quite possible to only have python3 available on a system.
Currently, when GDB configures, it looks for a 'python' executable.
If non is found then GDB will be built without python support. Or the
user needs to configure using --with-python=/usr/bin/python3.
This commit updates GDB's configure.ac script to first look for
'python', and then 'python3'. Now, on a system that only has a
python3 executable, GDB will automatically find, and use that in order
to provide python support, no user supplied configure arguments are
needed.
I've tested this on my local machine by removing the
python-unversioned-command package, confirming that there is no longer
a 'python' executable in my $PATH, and then rebuilding GDB from
scratch. GDB with this patch has python support.
Jan Beulich [Mon, 18 Jul 2022 09:20:44 +0000 (11:20 +0200)]
x86: correct VMOVSH attributes
Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by
suitable means, which would cause #UD). The memory operand form further
was using the wrong Masking value, thus allowing zeroing-masking to be
encoded for the store form (which would again cause #UD).
Jan Beulich [Mon, 18 Jul 2022 09:19:58 +0000 (11:19 +0200)]
x86: re-order insn template fields
This saves quite a number of shift instructions: The "operands" field
can now be retrieved by just masking (no shift), and extracting the
"extension_opcode" field now only requires a (signed) right shift, with
no prereq left one. (Of course there may be architectures where, in a
cross build, there might be no difference at all, e.g. when there are
suitable bitfield extraction insns.)
Tom de Vries [Mon, 18 Jul 2022 06:34:06 +0000 (08:34 +0200)]
[gdbsupport] Improve thread scheduling in parallel_for_each
When running a task using parallel_for_each, we get the following
distribution:
...
Parallel for: n_elements: 7271
Parallel for: minimum elements per thread: 10
Parallel for: elts_per_thread: 1817
Parallel for: elements on worker thread 0 : 1817
Parallel for: elements on worker thread 1 : 1817
Parallel for: elements on worker thread 2 : 1817
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 1820
...
Note that there are 4 active threads, and scheduling elts_per_thread on each
of those handles 4 * 1817 == 7268, leaving 3 "left over" elements.
These leftovers are currently handled in the main thread.
That doesn't seem to matter much for this example, but for say 10 threads and
99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18
elements.
Instead, distribute the left over elements over the worker threads, such that
we have:
...
Parallel for: elements on worker thread 0 : 1818
Parallel for: elements on worker thread 1 : 1818
Parallel for: elements on worker thread 2 : 1818
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 1817
...
Tom de Vries [Mon, 18 Jul 2022 04:20:38 +0000 (06:20 +0200)]
[gdb/testsuite] Allow override of ASAN_OPTIONS in lib/gdb.exp
Use set_sanitizer_default for ASAN_OPTIONS in lib/gdb.exp.
This allows us to override the default detect_leaks=0 setting, by manually
doing:
...
$ export ASAN_OPTIONS=detect_leaks=1
$ make check
...
Tested on x86_64-linux, by building with -fsanitize=address and running
test-case gdb.dwarf2/gdb-add-index.exp with and without
"export ASAN_OPTIONS=detect_leaks=1".
Tom de Vries [Mon, 18 Jul 2022 04:13:45 +0000 (06:13 +0200)]
[gdb/testsuite] Fix regression in step-indirect-call-thunk.exp with gcc 7
Since commit 43127ae5714 ("Fix gdb.base/step-indirect-call-thunk.exp") I run
into:
...
gdb compile failed, gcc: error: unrecognized command line option \
'-fcf-protection=none'; did you mean '-flto-partition=none'?
UNTESTED: gdb.base/step-indirect-call-thunk.exp: failed to prepare
...
The problem is that -fcf-protection is supported starting gcc 8, but I'm using
system gcc 7.5.0.
Fix this by only adding -fcf-protection=none for gcc 8 and later.
Tested on x86_64-linux, with gcc 7.5.0, 8.2.1 and 12.1.1.
Tom de Vries [Mon, 18 Jul 2022 03:34:01 +0000 (05:34 +0200)]
[gdbsupport] Add parallel_for_each_debug
Add a parallel_for_each_debug variable, set to false by default.
With an a.out compiled from hello world, we get with
parallel_for_each_debug == true:
...
$ gdb -q -batch a.out -ex start
...
Parallel for: n_elements: 7271
Parallel for: minimum elements per thread: 10
Parallel for: elts_per_thread: 1817
Parallel for: elements on worker thread 0 : 1817
Parallel for: elements on worker thread 1 : 1817
Parallel for: elements on worker thread 2 : 1817
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 1820
Temporary breakpoint 1, main () at /home/vries/hello.c:6
6 printf ("hello\n");
...
gdb-add-index always generates an error when libdebuginfod wasn't compiled in
gdb-add-index runs gdb with -iex 'set debuginfod enabled off'. If gdb
is not compiled against libdebuginfod this causes an unnecessary error
message to be printed to stderr indicating that gdb was not built with
debuginfod support.
Fix this by changing the 'set debuginfod enabled off' command to a
no-op when gdb isn't built with libdebuginfod.
Bruno Larsen [Tue, 28 Jun 2022 18:36:45 +0000 (15:36 -0300)]
gdb/testsuite: modernize gdb.base/maint.exp
gdb.base/maint.exp was using several gdb_expect statements, probably
because this test case predates the existance of gdb_test_multiple. This
commit updates the test case to use gdb_test_multiple, making it more
resilient to internal errors and such.
The only gdb_expect left in the testcase is one that specifically looks
for an internal error being triggered as a PASS.
Tom Tromey [Fri, 15 Jul 2022 15:38:32 +0000 (09:38 -0600)]
Add 'nibbles' to gdb.print_options
When I rebased and updated the print_options patch, I forgot to update
print_options to add the new 'nibbles' feature to the result. This
patch fixes the oversight. I'm checking this in.
Carl Love [Fri, 15 Jul 2022 15:30:43 +0000 (15:30 +0000)]
PowerPC: Add support for IEEE 128-bit format.
The test gdb.base/infcall-nested-structs-c.exp fails on a gdb assert
in function ppc64_sysv_abi_return_value in file gdb/ppc-sysv-tdep.c. The
assert is due to the missing IEEE 128-bit support in file
gdb/ppc-sysv-tdep.c.
The IBM long double was the initial float 128-bit support added by IBM
The IEEE 128-bit support, which is similar IBM long double support, was
made the default starting with GCC 12. The floating point format
differences include the number of bits used to encode the exponent
and significand. Also, IBM long double values are passed in a pair of
floating point registers. The IEEE 128-bit value is passed in a single
vector register.
This patch fixes the gdb_assert (ok); in function
ppc64_sysv_abi_return_value in gdb/ppc-sysv-tdep.c by adding IEEE FLOAT
128-bit type support for PowerPC.
The patch has been tested on Power 10, ELFv2. It fixes the following list
of regression failures on Power 10:
Tom Tromey [Tue, 7 Jun 2022 13:05:02 +0000 (07:05 -0600)]
Add 'summary' mode to Value.format_string
This adds a 'summary' mode to Value.format_string and to
gdb.print_options. For the former, it lets Python code format values
using this mode. For the latter, it lets a printer potentially detect
if it is being called in a backtrace with 'set print frame-arguments'
set to 'scalars'.
I considered adding a new mode here to let a pretty-printer see
whether it was being called in a 'backtrace' context at all, but I'm
not sure if this is really desirable.
Tom Tromey [Mon, 6 Jun 2022 15:54:45 +0000 (09:54 -0600)]
Expose current 'print' settings to Python
PR python/17291 asks for access to the current print options. While I
think this need is largely satisfied by the existence of
Value.format_string, it seemed to me that a bit more could be done.
First, while Value.format_string uses the user's settings, it does not
react to temporary settings such as "print/x". This patch changes
this.
Second, there is no good way to examine the current settings (in
particular the temporary ones in effect for just a single "print").
This patch adds this as well.
Carl Love [Fri, 15 Jul 2022 15:17:34 +0000 (15:17 +0000)]
PowerPC: fix for gdb.base/eh_return.exp
Disable the Traceback Table generation on PowerPC for this test. The
Traceback Table consists of a series of bit fields to indicate things like
the Traceback Table version, language, and specific information about the
function. The Traceback Table is generated following the end of the code
for every function by default. The Traceback Table is defined in the
PowerPC ELF ABI and is intended to support debuggers and exception
handlers. The Traceback Table is displayed in the disassembly of functions
by default and is part of the function length. The table is typically
interpreted by the disassembler as data represented by .long xxx entries.
Generation of the Traceback Table is disabled in this test using the
PowerPC specific gcc compiler option -mtraceback=no, the xlc option
additional_flags-qtable=none and the clang optons
-mllvm -xcoff-traceback-table=false. Disabling the Traceback Table
generation in this test results in the gdb_test_multiple statement
correctly locating the address of the bclr instruction before the statement
"End of assembler dump." in the disassembly output.
Tom de Vries [Thu, 14 Jul 2022 18:47:54 +0000 (20:47 +0200)]
[gdb/symtab] Fix data race in cooked_index_functions::expand_symtabs_matching
When building gdb with -fsanitize-threads and running test-case
gdb.ada/char_enum_unicode.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=21301)^M
Write of size 8 at 0x7b2000008080 by main thread:^M
#0 free <null> (libtsan.so.2+0x4c5e2)^M
#1 _dl_close_worker <null> (ld-linux-x86-64.so.2+0x4b7b)^M
#2 convert_between_encodings() charset.c:584^M
...
#21 cooked_index_functions::expand_symtabs_matching() read.c:18606
...
This is fixed by making cooked_index_functions::expand_symtabs_matching wait
for the cooked index finalization to be done.
Tom de Vries [Thu, 14 Jul 2022 08:20:16 +0000 (10:20 +0200)]
[gdb/build] Fix gdb build with gcc 4.8.5
When building gdb with gcc 4.8.5, we run into:
...
In file included from /usr/include/c++/4.8/future:43:0,
from gdbsupport/thread-pool.h:30,
from gdb/dwarf2/cooked-index.h:33,
from gdb/dwarf2/read.h:26,
from gdb/dwarf2/abbrev-cache.c:21:
/usr/include/c++/4.8/atomic: In instantiation of \
‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \
packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’:
gdb/dwarf2/read.h:332:44: required from here
/usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \
‘packed<dwarf_unit_type, 1ul>::packed()’
_Tp tmp;
^
...
Fix this by adding the default constructor for packed.
Tested on x86_64-linux, with gdb build with gcc 4.8.5.
Tom de Vries [Thu, 14 Jul 2022 06:19:00 +0000 (08:19 +0200)]
[gdb/symtab] Make per_cu->m_lang atomic
When building gdb with -fsanitize=thread and running test-case
gdb.dwarf2/inlined_subroutine-inheritance.exp, we run into a data race
between:
...
Read of size 1 at 0x7b2000003010 by thread T4:
#0 packed<language, 1ul>::operator language() const packed.h:54
#1 dwarf2_per_cu_data::set_lang(language) read.h:363
...
and:
...
Previous write of size 1 at 0x7b2000003010 by main thread:
#0 dwarf2_per_cu_data::set_lang(language) read.h:365
...
Tom de Vries [Thu, 14 Jul 2022 06:19:00 +0000 (08:19 +0200)]
[gdb/symtab] Make per_cu->unit_type atomic
With gdb with -fsanitize=thread and test-case gdb.ada/array_bounds.exp, I run
into a data race between:
...
Read of size 1 at 0x7b2000025f0f by main thread:
#0 packed<dwarf_unit_type, 1ul>::operator dwarf_unit_type() const packed.h:54
#1 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:339
...
and:
...
Previous write of size 1 at 0x7b2000025f0f by thread T3:
#0 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:341
...
Tom de Vries [Thu, 14 Jul 2022 06:19:00 +0000 (08:19 +0200)]
[gdb/symtab] Fix data race in ~charset_vector
When doing:
...
$ gdb ./outputs/gdb.ada/char_enum_unicode/foo -batch -ex "break foo.adb:26"
...
with a gdb build with -fsanitize=thread I run into a data race:
...
WARNING: ThreadSanitizer: data race (pid=30917)
Write of size 8 at 0x7b0400004070 by main thread:
#0 free <null> (libtsan.so.2+0x4c5e2)
#1 xfree<char> gdbsupport/gdb-xfree.h:37 (gdb+0x650f17)
#2 charset_vector::clear() gdb/charset.c:703 (gdb+0x651354)
#3 charset_vector::~charset_vector() gdb/charset.c:697 (gdb+0x6512d3)
#4 <null> <null> (libtsan.so.2+0x32643)
#5 captured_main_1 gdb/main.c:1310 (gdb+0xa3975a)
...
The problem is that we're freeing the charset_vector elements in the destructor,
which may still be used by a worker thread.
Fix this by not freeing the charset_vector elements in the destructor.
Alan Modra [Tue, 12 Jul 2022 01:40:08 +0000 (11:10 +0930)]
PowerPC: implement md_operand to parse register names
Allows register names to appear in symbol assignments, so for example
tocp = %r2
mr %r3,tocp
now assembles.
* gas/config/tc-ppc.c (REG_NAME_CNT): Delete, replace uses with
ARRAY_SIZE.
(register_name): Rename to..
(md_operand): ..this. Only handle %reg.
(cr_names): Rename to..
(cr_cond): ..this. Just keep conditions.
(ppc_parse_name): Add mode param. Search both cr_cond and
pre_defined_registers. Handle absolute and register symbol
values here rather than in expr.c:operand().
(md_assemble): Don't special case register name matching in
operands, except to set cr_operand as appropriate.
* gas/config/tc-ppc.h (md_operand): Don't define.
(md_parse_name, ppc_parse_name): Update.
* read.c (pseudo_set): Copy over entire O_register value.
* testsuite/gas/ppc/regsyms.d.
* testsuite/gas/ppc/regsyms.s: New test.
* testsuite/gas/ppc/ppc.exp: Run it.
A WIP version of a patch
(https://sourceware.org/pipermail/gdb-patches/2022-June/190202.html)
resulted in a bug that went unnoticed by the testuite, like so:
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread
continue
Continuing.
[New Thread 1251861.1251861]
No unwaited-for children left.
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
info threads
Id Target Id Frame
3 Thread 1251861.1251863 "no-unwaited-for" __pthread_clockjoin_ex (threadid=140737351558976, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
4 Thread 1251861.1251861 "no-unwaited-for" <unavailable> in ?? ()
The current thread <Thread ID 1> has terminated. See `help thread'.
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated
Somehow, above, GDB re-added the zombie leader back before printing
"No unwaited-for children left.". The "only thread 3 left, main
thread terminated" test should have caught this, but didn't. That is
because the test's regexp has a ".*" after the part that matches
thread 3. This commit tightens that regexp to catch such a bug. It
also tightens the "only main thread left, thread 2 terminated" test's
regexp in the same way.
Carl Love [Wed, 13 Jul 2022 15:09:33 +0000 (15:09 +0000)]
Fix gdb.base/step-indirect-call-thunk.exp
Due to recent changes in the default value of -fcf-protection for gcc, the
test gdb.base/step-indirect-call-thunk.exp fails on Intel X86-64 with the
error:
Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never
-mindirect-branch=thunk -mfunction-return=thunk -c -g
-o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o
/.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c
(timeout = 300) builtin_spawn -ignore SIGHUP gcc -fno-stack-protector
-fdiagnostics-color=never -mindirect-branch=thunk -mfunction-return=thunk -c
-g -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o
/.../binutils-gdb-current/gdb/testsuite/gdb.base/step-indirect-call-thunk.c
/.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c:
In function 'inc': /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c:
22:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible
22 | { /* inc.1 */
As stated in the error message the default "-fcf-protection" and
"-mindirect-branch' are in compatible. The fcf-protection argument needs
to be "-fcf-protection=none" for the test to compile on Intel.
The gcc command line "-mindirect-branch' is an Intel specific and will give
an error on other platforms. A check for X86 is added so the test will
only run on X86 platforms.
The patch has been tested and verified on Power 10 and Intel X86-64 systems
with no regressions.
Pedro Alves [Tue, 12 Jul 2022 21:14:37 +0000 (22:14 +0100)]
Fix "until LINE" in main, when "until" runs into longjmp
With a test like this:
1 #include <dlfcn.h>
2 int
3 main ()
4 {
5 dlsym (RTLD_DEFAULT, "FOO");
6 return 0;
7 }
and then "start" followed by "until 6", GDB currently incorrectly
stops inside the runtime loader, instead of line 6. Vis:
...
Temporary breakpoint 1, main () at until.c:5
4 {
(gdb) until 6
0x00007ffff7f0a90d in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffdb00, operate=<optimized out>, args=0x7ffff7f0a90d <__GI__dl_catch_exception+109>) at dl-error-skeleton.c:206
206 dl-error-skeleton.c: No such file or directory.
(gdb)
The problem is related to longjmp handling -- dlsym internally
longjmps on error. The testcase can be reduced to this:
1 #include <setjmp.h>
2 void func () {
3 jmp_buf buf;
4 if (setjmp (buf) == 0)
5 longjmp (buf, 1);
6 }
7
8 int main () {
9 func ();
10 return 0; /* until to here */
11 }
and then with "start" followed by "until 10", GDB currently
incorrectly stops at line 4 (returning from setjmp), instead of line
10.
The problem is that the BPSTAT_WHAT_CLEAR_LONGJMP_RESUME code in
infrun.c fails to find the initiating frame, and so infrun thinks that
the longjmp jumped somewhere outer to "until"'s originating frame.
Here:
case BPSTAT_WHAT_CLEAR_LONGJMP_RESUME:
{
struct frame_info *init_frame;
/* There are several cases to consider.
1. The initiating frame no longer exists. In this case we
must stop, because the exception or longjmp has gone too
far.
/* For Cases 1 and 2, remove the step-resume breakpoint, if it
exists. */
delete_step_resume_breakpoint (ecs->event_thread);
end_stepping_range (ecs); // case 1., so we stop.
}
The initiating frame is set by until_break_command ->
set_longjmp_breakpoint. The initiating frame is supposed to be the
frame that is selected when the command was issued, but
until_break_command instead passes the frame id of the _caller_ frame
by mistake. When the "until LINE" command is issued from main, the
caller frame is the caller of main. When later infrun tries to find
that frame by id, it fails to find it, because frame_find_by_id
doesn't unwind past main.
The bug is that we passed the caller frame's id to
set_longjmp_breakpoint. We should have passed the selected frame's id
instead.
Enze Li [Mon, 11 Jul 2022 12:53:48 +0000 (20:53 +0800)]
gdbserver: remove unused variable
When building with clang 15, I got this error:
CXX server.o
server.cc:2985:10: error: variable 'new_argc' set but not used [-Werror,-Wunused-but-set-variable]
int i, new_argc;
^
Remove the unused variable to eliminate the error.
Tested by rebuilding on x86_64-linux with clang 15.
Tom de Vries [Wed, 13 Jul 2022 10:20:53 +0000 (12:20 +0200)]
[gdb/symtab] Make per_cu->set_lang more strict
We have in per_cu->set_lang this comment:
...
void set_lang (enum language lang)
{
/* We'd like to be more strict here, similar to what is done in
set_unit_type, but currently a partial unit can go from unknown to
minimal to ada to c. */
...
Fix this by not setting m_lang for partial units.
This requires us to move the m_unit_type initialization to ensure that
m_unit_type is initialized before per_cu->m_lang.
Tested on x86_64-linux, with native and target board cc-with-dwz-m.
projects / thirdparty / binutils-gdb.git / log
