diff options
author | Andreas Arnez <arnez@linux.vnet.ibm.com> | 2016-11-24 17:48:03 +0100 |
---|---|---|
committer | Andreas Arnez <arnez@linux.vnet.ibm.com> | 2016-11-24 17:48:03 +0100 |
commit | 22347e554cd7ba2a0bf36dc81ebfcbe2e2fd74af (patch) | |
tree | 106513aca860aaa113cd2f8b37bf134a7ee5de25 /config.sub | |
parent | da5b30da2d1167591aa8d71b543f97bfdc2ec2a2 (diff) | |
download | gdb-22347e554cd7ba2a0bf36dc81ebfcbe2e2fd74af.zip gdb-22347e554cd7ba2a0bf36dc81ebfcbe2e2fd74af.tar.gz gdb-22347e554cd7ba2a0bf36dc81ebfcbe2e2fd74af.tar.bz2 |
Fix copy_bitwise()
When the user writes or reads a variable whose location is described
with DWARF pieces (DW_OP_piece or DW_OP_bit_piece), GDB's helper
function copy_bitwise is invoked for each piece. The implementation of
this function has a bug that may result in a corrupted copy, depending
on alignment and bit size. (Full-byte copies are not affected.)
This rewrites copy_bitwise, replacing its algorithm by a fixed version,
and adding an appropriate test case. Without the fix the new test case
fails, e.g.:
print def_t
$2 = {a = 0, b = 4177919}
(gdb) FAIL: gdb.dwarf2/nonvar-access.exp: print def_t
Written in binary, the wrong result above looks like this:
01111111011111111111111
Which means that two zero bits have sneaked into the copy of the
original all-one bit pattern. The test uses this simple all-one value
in order to avoid another GDB bug that causes the DWARF piece of a
DW_OP_stack_value to be taken from the wrong end on big-endian
architectures.
gdb/ChangeLog:
* dwarf2loc.c (extract_bits_primitive): Remove.
(extract_bits): Remove.
(copy_bitwise): Rewrite. Fixes a possible corruption that may
occur for non-byte-aligned copies.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/nonvar-access.exp: Add a test for accessing
non-byte-aligned bit fields.
Diffstat (limited to 'config.sub')
0 files changed, 0 insertions, 0 deletions