GDB Agent for RTEMS on new powerpc/virtex BSP
Robert S. Grimes
rsg at alum.mit.edu
Wed Sep 5 23:41:46 UTC 2007
Hi,
I'm trying to use Till Straumann's "GDB Agent for RTEMS" working on
RTEMS-4.7.99.2, using the powerpc/virtex BSP. This BSP supports Xilinx
Virtex-4 and its embedded PPC-403 PowerPC. This PPC/BSP combination
uses the "new exceptions" model, but has no floating point unit. My
application is being developed using C++.
With a bit of help, I've been able to build a suitably patched gdb, and
with some help elsewhere, I've even got Insight to recognize the new
rtems-remote target.
I've also been able to build the agent, but that's about it. There were
some major issues, mainly centered around the lack of FP. But I did get
it to compile; attached is a patch file describing the changes. (Note:
yes, a better symbol could, and should, be chosen).
When I attempt to connect, however, I get an exception 0. Here is the
gdb session:
(gdb) target rtems-remote 192.168.0.69:2159
Remote debugging using 192.168.0.69:2159
[New Thread a010006]
warning: no shared library support for this OS / ABI
[Switching to Thread a010006]
helper_thread (Ignoring packet error, continuing...
arg=Reply contains invalid hex digit 116
) at rtems-stub.c:621
621 sleep(1);
Ignoring packet error, continuing...
Ignoring packet error, continuing...
warning: remote target does not support CRC operation - skipping...
Remote communication error: Connection reset by peer.
(gdb)
Meanwhile, the serial console shows this, which is displayed immediately
upon entry of the "target rtems-remote ..." command; the remainder of
the gdb output is displayed, a line or two at a time, a second or two apart.
exception handler called for exception 0
Next PC or Address of fault = C0276922
Saved MSR = 61000000
R0 = 0
R1 = 0
R2 = 0
R3 = 0
R4 = 0
R5 = 0
R6 = 0
R7 = 0
R8 = 0
R9 = 0
R10 = 0
R11 = 0
R12 = 0
R13 = FFFE09
R14 = 54FFFE02
R15 = 40FFFE01
R16 = D0000000
R17 = 800000
R18 = 1000000
R19 = 0
R20 = 0
R21 = 0
R22 = 0
R23 = 3000000
R24 = 1FFFFFF
R25 = FF000000
R26 = 0
R27 = 0
R28 = 0
R29 = 820401
R30 = 0
R31 = 820C01
CR = 0
CTR = 3821401
XER = 0
LR = 821C01
MSR = 0
DAR = BA8C2B
Stack Trace:
IP: 0xC0276922, LR: 0x00821C01
--^ 0x00000000
Here are the differences:
--- RTEMS_gdb_stub_1.4/rtems-gdb-stub-ppc-shared.c Wed Sep 05
19:09:14 2007
+++ RTEMS_gdb_stub_1.4/rtems-gdb-stub-ppc-shared.rsg.c Wed Sep 05
19:11:20 2007
@@ -123,11 +123,13 @@
}
if ( (tcb = get_tcb(msg->tid)) ) {
+#ifdef RSG_USE_FP
Context_Control_fp *fpc = tcb->fp_context;
if ( fpc ) {
memcpy(buf + FPR0_OFF, &fpc->f[0], 32*8 );
memcpy(buf + FPSCR_OFF, &fpc->fpscr, 4);
}
+#endif
if (!f) {
Frame sfr = (Frame)tcb->Registers.gpr1;
unsigned pcdummy = tcb->Registers.pc - 4;
@@ -162,12 +164,14 @@
}
if ( msg->tid && (tcb = get_tcb(msg->tid)) ) {
+#ifdef RSG_USE_FP
Context_Control_fp *fpc = tcb->fp_context;
if ( fpc ) {
memcpy(&fpc->f[0], buf+FPR0_OFF, 32*8 );
memset(&fpc->fpscr, 0, sizeof(fpc->fpscr));
memcpy(&fpc->fpscr, buf + FPSCR_OFF, 4);
}
+#endif
if ( !f ) {
/* setup TCB */
memcpy(&tcb->Registers.gpr1, buf + (GPR0_OFF + 4),
2 *4);
@@ -240,16 +244,20 @@
switch ( f->_EXC_number ) {
case ASM_MACH_VECTOR :
+#ifdef RSG_USE_FP
_BSP_clear_hostbridge_errors(1,0);
+#endif
msg.sig = SIGBUS;
break;
case ASM_PROT_VECTOR :
case ASM_ISI_VECTOR :
case ASM_ALIGN_VECTOR :
+#ifdef RSG_USE_FP
case ASM_IMISS_VECTOR :
case ASM_DLMISS_VECTOR :
case ASM_DSMISS_VECTOR :
+#endif
msg.sig = SIGSEGV;
break;
I suspect my changes are way too simple-minded, but maybe I'm not
totally out in left field. The first two changes skip copying of
non-existent FP registers (I think). The ...hostbridge... call I don't
have a concrete clue about, but I am guessing that isn't necessary for
my BSP (could be wrong, of course!). The last change - deleting the
undefined vectors in the switch statement - I would not expect to be a
problem.
With a lot of work, I can problem get this figured out, but I'm hoping
someone more expert than me might have some clues to save me some grief.
Thanks!
-Bob
BTW: It looks like Insight is going to work too, assuming I can get this
problem resolved, as it fails in the exact same way! One of those
not-so-rare situations where a failure actually makes you feel good! ;-)
More information about the users
mailing list