Wind River Support Network

HomeDefectsLIN6-8575
Fixed

LIN6-8575 : Cannot attach to an existing process when connecting through GDB server running on Freescale e6500

Created: Oct 16, 2014    Updated: Dec 3, 2018
Resolved Date: Dec 23, 2014
Found In Version: 6.0.0.13
Fix Version: 6.0.0.16
Severity: Standard
Applicable for: Wind River Linux 6
Component/s: Toolchain

Description

*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.

Workaround

replace gdbserver with the one in attached tarball named gdbserver-ppc64e6500-4.8-40.tar.gz

Other Downloads


Live chat
Online