aboutsummaryrefslogtreecommitdiff
path: root/config.sub
diff options
context:
space:
mode:
authorAndreas Arnez <arnez@linux.vnet.ibm.com>2016-11-24 17:48:03 +0100
committerAndreas Arnez <arnez@linux.vnet.ibm.com>2016-11-24 17:48:03 +0100
commit22347e554cd7ba2a0bf36dc81ebfcbe2e2fd74af (patch)
tree106513aca860aaa113cd2f8b37bf134a7ee5de25 /config.sub
parentda5b30da2d1167591aa8d71b543f97bfdc2ec2a2 (diff)
downloadgdb-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