Fixed
Created: Dec 28, 2014
Updated: Sep 8, 2018
Resolved Date: May 17, 2015
Found In Version: 7.0
Fix Version: 7.0.0.6
Severity: Standard
Applicable for: Wind River Linux 7
Component/s: Toolchain
*Steps to reproduce:*
On target:
$gdbserver --multi :12345
On host (or target):
$gdb
(gdb) target extended-remote <target-ip>:12345
(gdb) attach <pid>
Make sure that the binaries of the process that is being attached to and gdbserver are targeting 64-bit.
*Result:*
warning: Selected architecture powerpc:common64 is not compatible with reported target architecture powerpc:common
warning: Architecture rejected target-supplied description
Reply contains invalid hex digit 59
After which the program counter appears to go off stack and the debugged process exits due to a segmentation fault.
Using GDB directly on target without GDB server and attaching to existing process works fine.
*Additional info:*
*File* gdb/gdbserver/linux-ppc-low.c
*Function* ppc_arch_setup (void)
*At*
/* Only if the high bit of the MSR is set, we actually have
a 64-bit inferior. */
if (msr < 0)***<--this check fails!*
But e6500 seems to be a "Book E" power architecture which has a
different Machine Status Register (MSR) layout:
- Power ISA has MSR_SF in bit 63 which is used to detect if running in
32 or 64-bit.
- Book E has MSR_CM in bit 32 (first half of long is zero) which is used
to detect if running in 32 or 64-bit.
Making the attached process appear as 32-bit in the eyes of GDB on e6500
even if it is 64-bit. If the above check is removed, for testing
purpose, attaching works as expected.
Similar problem appears to be in:
*File* gdb/ppc-linux-nat.c
*Function* ppc_linux_target_wordsize
*At*
msr = (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0);
if (errno == 0 && msr < 0)***<--this check fails!*
which seems to report 4 instead of 8 but this is not related to the
original problem.
I made some further investigation and as far as I can tell the problem
actually always exists with the difference being that a processes
launched by GDB get an MSR that looks like this:
FFFFFFFF8002d000
While the MSR looks like this when GDB attaches to an already existing
process:
000000008002d000
Meaning that in the first case the MSR will always be seen as negative
while in the second case the opposite is true.
I also looked at the Freescale gdb.git:
http://git.freescale.com/git/cgit.cgi/ppc/sdk/gdb.git/tree/gdb/gdbserver?id=fsl-sdk-v1.6
but I could not find anything interesting from that.
