diff options
author | Tom Tromey <tromey@adacore.com> | 2021-06-18 13:08:33 -0600 |
---|---|---|
committer | Tom Tromey <tromey@adacore.com> | 2021-07-16 08:23:47 -0600 |
commit | cc9d6997a5b23d0c8e1960f6c0b5f5cdf456d4e9 (patch) | |
tree | 98b8274e28e753f9ba06b8c17975fabba46199ac /elfcpp | |
parent | 05a1dd47cc9b6fcc8ec112bd0b68b36567ccbb39 (diff) | |
download | gdb-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