diff options
author | Tom de Vries <tdevries@suse.de> | 2023-08-16 23:43:25 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2023-08-16 23:43:25 +0200 |
commit | eeee4389cf3725e729b0a477515afd830b34b9f0 (patch) | |
tree | eed75798355e070fe995ba38cc1d360abfb51721 /config-ml.in | |
parent | 033bc52bb6190393c8eed80925fa78cc35b40c6d (diff) | |
download | gdb-eeee4389cf3725e729b0a477515afd830b34b9f0.zip gdb-eeee4389cf3725e729b0a477515afd830b34b9f0.tar.gz gdb-eeee4389cf3725e729b0a477515afd830b34b9f0.tar.bz2 |
[gdb/symtab] Handle self-reference DIE
While working on a dwarf assembly test-case I accidentally created the
following pathological dwarf:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xbe>
...
and noticed gdb segfaulting during cooked index creating due to running out of
stack. This is a regression from gdb-12, where gdb just hung.
Fix this by inhibiting the scan_attributes self-recursion for self-references.
The same test-case with -readnow makes gdb hang, so also fix this in
dwarf2_attr and follow_die_ref.
Note that this doesn't fix the same problems for the more complicated case of:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xc6>
<1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
<c7> DW_AT_name : c2
<ca> DW_AT_specification: <0xbe>
...
but the approach for deciding whether to fix pathological dwarf cases is as
per PR27981 comment 3:
...
yes if it is cheap/obvious, and no if it is something complicated or expensive.
...
and at this point I'm not sure whether fixing this will fall in the first
category.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'config-ml.in')
0 files changed, 0 insertions, 0 deletions