This is the mail archive of the
gdb-testers@sourceware.org
mailing list for the GDB project.
[binutils-gdb] [Cell/B.E.] Fix regression due to gdbarch_significant_addr_bit
- From: sergiodj+buildbot at sergiodj dot net
- To: gdb-testers at sourceware dot org
- Date: Wed, 20 Dec 2017 08:37:31 -0500
- Subject: [binutils-gdb] [Cell/B.E.] Fix regression due to gdbarch_significant_addr_bit
- Authentication-results: sourceware.org; auth=none
*** TEST RESULTS FOR COMMIT 396d3980f518cfc9a936e3fb8138b0492399525a ***
Author: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Branch: master
Commit: 396d3980f518cfc9a936e3fb8138b0492399525a
[Cell/B.E.] Fix regression due to gdbarch_significant_addr_bit
On Cell/B.E. multi-architecture debugging we use a "merged" address space
that encodes both the main PowerPC address space and the local store address
spaces of all active SPUs. This will always occupy 64 bits.
However, gdbarch_addr_bit is set to 32 on SPU, and may be set to 32 as well
on PowerPC. Since the new gdbarch_significant_addr_bit defaults to the
value of gdbarch_addr_bit, this means addresses may be improperly truncated.
Work around this problem by explicitly setting gdbarch_significant_addr_bit
to 64 both for the SPU target and also for PowerPC target that support
Cell/B.E. execution.
gdb/ChangeLog:
2017-12-20 Ulrich Weigand <uweigand@de.ibm.com>
* spu-tdep.c (spu_gdbarch_init): Set set_gdbarch_significant_addr_bit
to 64 bits.
(ppc_linux_init_abi): Likewise, if Cell/B.E. is supported.