aboutsummaryrefslogtreecommitdiff
path: root/elfcpp
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2021-06-18 13:08:33 -0600
committerTom Tromey <tromey@adacore.com>2021-07-16 08:23:47 -0600
commitcc9d6997a5b23d0c8e1960f6c0b5f5cdf456d4e9 (patch)
tree98b8274e28e753f9ba06b8c17975fabba46199ac /elfcpp
parent05a1dd47cc9b6fcc8ec112bd0b68b36567ccbb39 (diff)
downloadgdb-cc9d6997a5b23d0c8e1960f6c0b5f5cdf456d4e9.zip
gdb-cc9d6997a5b23d0c8e1960f6c0b5f5cdf456d4e9.tar.gz
gdb-cc9d6997a5b23d0c8e1960f6c0b5f5cdf456d4e9.tar.bz2
Fix array stride bug
Investigation of using the Python API with an Ada program showed that an array of dynamic types was not being handled properly. I tracked this down to an oddity of how array strides are handled. In gdb, an array stride can be attached to the range type, via the range_bounds object. However, the stride can also be put into the array's first field. From create_range_type_with_stride: else if (bit_stride > 0) TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride; It's hard to be sure why this is done, but I would guess a combination of historical reasons plus a desire (mentioned in a comment somewhere) to avoid modifying the range type. This patch fixes the problem by changing type::bit_stride to understand this convention. It also fixes one spot that reproduces this logic. Regression tested on x86-64 Fedora 32.
Diffstat (limited to 'elfcpp')
0 files changed, 0 insertions, 0 deletions