From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jonathan Larmour <jlarmour@cygnus.co.uk>
To: guinan@bluebutton.com
Cc: Ecos Discussion List <ecos-discuss@sourceware.cygnus.com>
Subject: Re: [ECOS] powerpc-eabi-gdb woes (fwd)
Date: Sat, 30 Oct 1999 08:03:00 -0000
Message-id: <381B08B8.7FE96AFA@cygnus.co.uk>
References: <Pine.LNX.4.10.9910282028210.2825-100000@gemini.home.net>
X-SW-Source: 1999-10/msg00127.html

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