aboutsummaryrefslogtreecommitdiff
path: root/gdb/c-lang.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2023-01-20 11:51:54 -0500
committerSimon Marchi <simon.marchi@polymtl.ca>2023-01-20 11:51:54 -0500
commitb70bff5ea52550c7cd48af7579a75ac2624ec13d (patch)
tree6a9f9cf38c04c68d7285e18175f1487010360c5e /gdb/c-lang.c
parent173628ae6896d4cadddcb0c3034206d7cc9fb19a (diff)
downloadgdb-b70bff5ea52550c7cd48af7579a75ac2624ec13d.zip
gdb-b70bff5ea52550c7cd48af7579a75ac2624ec13d.tar.gz
gdb-b70bff5ea52550c7cd48af7579a75ac2624ec13d.tar.bz2
gdb/dwarf: fix UBsan crash in read_subrange_type
When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the `gnat-11` package installed (not `gnat`), with UBSan activated, I get: (gdb) break foo.adb:40 /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int' The problematic DIEs are: 0x00001460: DW_TAG_subrange_type DW_AT_lower_bound [DW_FORM_data1] (0x00) DW_AT_upper_bound [DW_FORM_data16] (ffffffffffffffff3f00000000000000) DW_AT_name [DW_FORM_strp] ("foo__packed_array___XP7___XDLU_0__1180591620717411303423") DW_AT_type [DW_FORM_ref4] (0x0000153f "long_long_long_unsigned") DW_AT_GNAT_descriptive_type [DW_FORM_ref4] (0x0000147e) DW_AT_artificial [DW_FORM_flag_present] (true) 0x0000153f: DW_TAG_base_type DW_AT_byte_size [DW_FORM_data1] (0x10) DW_AT_encoding [DW_FORM_data1] (DW_ATE_unsigned) DW_AT_name [DW_FORM_strp] ("long_long_long_unsigned") DW_AT_artificial [DW_FORM_flag_present] (true) When processed by this code: negative_mask = -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1)); if (low.kind () == PROP_CONST && !base_type->is_unsigned () && (low.const_val () & negative_mask)) low.set_const_val (low.const_val () | negative_mask); When the base type's length (16 bytes in this case) is larger than a ULONGEST (typically 8 bytes), the bit shift is too large. My obvious fix is just to skip the fixup for base types larger than a ULONGEST (8 bytes). I don't think we really handle constant attribute values larger than 8 bytes anyway, so this is part of a much larger problem. Add a test that replicates this situation, but uses bounds that fit in a signed 64 bit, so we get a sensible result. Change-Id: I8d0a24f3edd83b44e0761a0ce38922d3e2e112fb Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29386
Diffstat (limited to 'gdb/c-lang.c')
0 files changed, 0 insertions, 0 deletions