aboutsummaryrefslogtreecommitdiff
path: root/opcodes/m10200-dis.c
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2018-04-23 13:41:27 -0600
committerTom Tromey <tom@tromey.com>2018-04-30 11:25:32 -0600
commite11fb955fbab035748fa53ffc30c103157a284b6 (patch)
tree655310cf73667f546e4742ebc529d030023734c2 /opcodes/m10200-dis.c
parent2fff16dd8c25831fb5fbf198ca86d5befff629be (diff)
downloadfsf-binutils-gdb-e11fb955fbab035748fa53ffc30c103157a284b6.zip
fsf-binutils-gdb-e11fb955fbab035748fa53ffc30c103157a284b6.tar.gz
fsf-binutils-gdb-e11fb955fbab035748fa53ffc30c103157a284b6.tar.bz2
Remove long_long_align_bit gdbarch attribute
This removes the long_long_align_bit gdbarch attribute in favor of type_align. This uncovered two possible issues. First, arc-tdep.c claimed that long long alignment was 32 bits, but as discussed on the list, ARC has a maximum alignment of 32 bits, so I've added an arc_type_align function to account for this. Second, jit.c, the sole user of long_long_align_bit, was confusing "long long" with uint64_t. The relevant structure is defined in the JIT API part of the manual as: struct jit_code_entry { struct jit_code_entry *next_entry; struct jit_code_entry *prev_entry; const char *symfile_addr; uint64_t symfile_size; }; I've changed this code to use uint64_t. 2018-04-30 Tom Tromey <tom@tromey.com> * jit.c (jit_read_code_entry): Use type_align. * i386-tdep.c (i386_gdbarch_init): Don't call set_gdbarch_long_long_align_bit. * gdbarch.sh: Remove long_long_align_bit. * gdbarch.c, gdbarch.h: Rebuild. * arc-tdep.c (arc_type_align): New function. (arc_gdbarch_init): Use arc_type_align. Don't call set_gdbarch_long_long_align_bit.
Diffstat (limited to 'opcodes/m10200-dis.c')
0 files changed, 0 insertions, 0 deletions