aboutsummaryrefslogtreecommitdiff
path: root/config-ml.in
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2023-08-16 23:43:25 +0200
committerTom de Vries <tdevries@suse.de>2023-08-16 23:43:25 +0200
commiteeee4389cf3725e729b0a477515afd830b34b9f0 (patch)
treeeed75798355e070fe995ba38cc1d360abfb51721 /config-ml.in
parent033bc52bb6190393c8eed80925fa78cc35b40c6d (diff)
downloadgdb-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