[ECOS] powerpc-eabi-gdb woes (fwd)

[ECOS] powerpc-eabi-gdb woes (fwd)

[Jamie Guinan]

(Duh, this never got out to the list - no wonder there
 were no replies.  :P )

---------- Forwarded message ----------
Date: Tue, 26 Oct 1999 14:04:08 -0400 (EDT)
From: Jamie Guinan <guinan@bluebutton.com>
To: ecos-discuss@bluebutton.com
                 ^^^^^^^^^^^^^^  (silly me)
Subject: powerpc-eabi-gdb woes


Hi all,

I'm working with an MBX board, MPC821 @ 40Mhz.

I've run into a few problems with powerpc-eabi-gdb, and
I wanted to see if anyone else has seen similar problems.

1) GDB prints insane values for local variables.  I found
this while debugging a simple program without eCos (GDB is
using the GDB stub in ROM in this case), and without
optimization.

Test case:
http://www.bluebutton.com/ecos-discuss/10-26-1999/test5/Makefile
http://www.bluebutton.com/ecos-discuss/10-26-1999/test5/test5.c

Test session:
$ powerpc-eabi-gdb -b 38400 test5
(gdb) target remote /dev/ttyS0
(gdb) load
...
(gdb) b main
(gdb) cont
...
Breakpoint 1, main () at test5.c:21
21	  i=90;
(gdb) n
22	  j=99;
(gdb) p i
$1 = 2087191462
^^^^^^^^^^^^^^^

2) I then tried building a program *with* eCos, but I get
what look like GDB protocol errors when trying to print local variables.

Test case:
http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/Makefile
http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/avg3.c
http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/test6.c

Test session:
$ powerpc-eabi-gdb -b 38400 test6
(gdb) target remote /dev/ttyS0
(gdb) load
Loading section .vectors, size 0x2000 lma 0x10000
Loading section .text, size 0x1ae7c lma 0x12000
Loading section .rodata, size 0xcc54 lma 0x2ce80
ding section .data, size 0x888 lma 0x39ad8
Start address 0x10100 , load size 172888
Transfer rate: 26096 bits/sec.
(gdb) b main
Breakpoint 1 at 0x124c0: file test6.c, line 10.
(gdb) cont
Continuing.
+++
Breakpoint 1, main () at test6.c:10
10	  a=4;
(gdb) n
11	  b=50;
(gdb) p a
Reply contains invalid hex digit 84
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I've repeated this several times, it happens each time.

For this ram-based configuration, I used the following script
to create the target "install" directory,
http://www.bluebutton.com/ecos-discuss/10-26-1999/build-ecos-mbx-ram.sh

The script requires this patch to set up 40Mhz operation and GDB params,
http://www.bluebutton.com/ecos-discuss/10-26-1999/ecos-mbx-ram-pkgconf.patch

Thanks in advance...
-Jamie

================================================================
Jamie Guinan                         Blue Button Solutions, Inc.
guinan@bluebutton.com                  http://www.bluebutton.com
================================================================

Re: [ECOS] powerpc-eabi-gdb woes (fwd)

[Jonathan Larmour]

Jamie Guinan wrote:
> 1) GDB prints insane values for local variables.  I found
> this while debugging a simple program without eCos (GDB is
> using the GDB stub in ROM in this case), and without
> optimization.
> 
> 21        i=90;
> (gdb) n
> 22        j=99;
> (gdb) p i
> $1 = 2087191462
> ^^^^^^^^^^^^^^^

As (I think) someone else pointed out, you should disable the
CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT and
CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM config options, but I haven't tried
this with your test to see if it fixes it.
 
> 2) I then tried building a program *with* eCos, but I get
> what look like GDB protocol errors when trying to print local variables.
> 
> Test case:
> http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/Makefile
> http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/avg3.c
> http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/test6.c
> 
> Test session:
> $ powerpc-eabi-gdb -b 38400 test6
> (gdb) target remote /dev/ttyS0
> (gdb) load
> Loading section .vectors, size 0x2000 lma 0x10000
> Loading section .text, size 0x1ae7c lma 0x12000
> Loading section .rodata, size 0xcc54 lma 0x2ce80
> ding section .data, size 0x888 lma 0x39ad8
> Start address 0x10100 , load size 172888
> Transfer rate: 26096 bits/sec.
> (gdb) b main
> Breakpoint 1 at 0x124c0: file test6.c, line 10.
> (gdb) cont
> Continuing.
> +++
> Breakpoint 1, main () at test6.c:10
> 10        a=4;
> (gdb) n
> 11        b=50;
> (gdb) p a
> Reply contains invalid hex digit 84
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I've repeated this several times, it happens each time.

Ah yes, I've seen that one before (I think it was even me who fixed it). It
should be fixed in the latest anonCVS version. The problem is that some
boards, like the MBX, don't like bad memory accesses and the HAL you have
can't catch them.

You need to change cyg_hal_exception_handler in
hal/powerpc/arch/VERSION/src/hal_misc.c. Make it look like this:

externC void *__mem_fault_handler;

void
cyg_hal_exception_handler(HAL_SavedRegisters *regs)
{
#ifdef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS

    // If we caught an exception inside the stubs, see if we were expecting
it
    // and if so jump to the saved address
    if (__mem_fault_handler) {
        regs->pc = (CYG_ADDRWORD)__mem_fault_handler;
        return; // Caught an exception inside stubs        
    }

    // Set the pointer to the registers of the current exception
    // context. At entry the GDB stub will expand the
    // HAL_SavedRegisters structure into a (bigger) register array.
    _hal_registers = regs;
[etc.]

I think that's all that's required. As I said, anonCVS should have this too.
Let the list know if this all works for you.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] powerpc-eabi-gdb woes (fwd) [RESOLVED]

[Jamie Guinan]

On Sat, 30 Oct 1999, Jonathan Larmour wrote:

> Jamie Guinan wrote:
> > 1) GDB prints insane values for local variables.  I found
> > this while debugging a simple program without eCos (GDB is
> > using the GDB stub in ROM in this case), and without
> > optimization.
> > 
> > 21        i=90;
> > (gdb) n
> > 22        j=99;
> > (gdb) p i
> > $1 = 2087191462
> > ^^^^^^^^^^^^^^^
> 
> As (I think) someone else pointed out, you should disable the
> CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT and
> CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM config options, but I haven't tried
> this with your test to see if it fixes it.

Jesper suggested I #undef those settings in hal.h, and that did
fix the insane-values problem.

> > 2) I then tried building a program *with* eCos, but I get
> > what look like GDB protocol errors when trying to print local variables.
> > 
> > Test case:
> > http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/Makefile
> > http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/avg3.c
> > http://www.bluebutton.com/ecos-discuss/10-26-1999/test6/test6.c
> > 
> > Test session:
> > $ powerpc-eabi-gdb -b 38400 test6
> > (gdb) target remote /dev/ttyS0
> > (gdb) load
> > Loading section .vectors, size 0x2000 lma 0x10000
> > Loading section .text, size 0x1ae7c lma 0x12000
> > Loading section .rodata, size 0xcc54 lma 0x2ce80
> > ding section .data, size 0x888 lma 0x39ad8
> > Start address 0x10100 , load size 172888
> > Transfer rate: 26096 bits/sec.
> > (gdb) b main
> > Breakpoint 1 at 0x124c0: file test6.c, line 10.
> > (gdb) cont
> > Continuing.
> > +++
> > Breakpoint 1, main () at test6.c:10
> > 10        a=4;
> > (gdb) n
> > 11        b=50;
> > (gdb) p a
> > Reply contains invalid hex digit 84
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > I've repeated this several times, it happens each time.
> 
> Ah yes, I've seen that one before (I think it was even me who fixed it). It
> should be fixed in the latest anonCVS version. The problem is that some
> boards, like the MBX, don't like bad memory accesses and the HAL you have
> can't catch them.
> 
> You need to change cyg_hal_exception_handler in
> hal/powerpc/arch/VERSION/src/hal_misc.c. Make it look like this:
> 
> externC void *__mem_fault_handler;
> 
> void
> cyg_hal_exception_handler(HAL_SavedRegisters *regs)
> {
> #ifdef CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS
> 
>     // If we caught an exception inside the stubs, see if we were expecting
> it
>     // and if so jump to the saved address
>     if (__mem_fault_handler) {
>         regs->pc = (CYG_ADDRWORD)__mem_fault_handler;
>         return; // Caught an exception inside stubs        
>     }
> 
>     // Set the pointer to the registers of the current exception
>     // context. At entry the GDB stub will expand the
>     // HAL_SavedRegisters structure into a (bigger) register array.
>     _hal_registers = regs;
> [etc.]
> 
> I think that's all that's required. As I said, anonCVS should have this too.
> Let the list know if this all works for you.

I haven't seen this problem again, and I'm working out of anonCVS at the
moment, so I do have the code you quoted.

Now I'm back to trying to send data out SMC2.  Its been a few weeks,
so after I refresh my memory I'll post here and maybe a bug report
if I can't get it going.

-Jamie