diff options
author | Tom Tromey <tom@tromey.com> | 2018-04-23 13:41:27 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2018-04-30 11:25:32 -0600 |
commit | e11fb955fbab035748fa53ffc30c103157a284b6 (patch) | |
tree | 655310cf73667f546e4742ebc529d030023734c2 /gold/resolve.cc | |
parent | 2fff16dd8c25831fb5fbf198ca86d5befff629be (diff) | |
download | gdb-e11fb955fbab035748fa53ffc30c103157a284b6.zip gdb-e11fb955fbab035748fa53ffc30c103157a284b6.tar.gz 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 'gold/resolve.cc')
0 files changed, 0 insertions, 0 deletions