From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jamie Guinan <guinan@bluebutton.com>
To: Jonathan Larmour <jlarmour@cygnus.co.uk>
Cc: Ecos Discussion List <ecos-discuss@sourceware.cygnus.com>
Subject: Re: [ECOS] powerpc-eabi-gdb woes (fwd) [RESOLVED]
Date: Tue, 09 Nov 1999 13:17:00 -0000
Message-id: <Pine.LNX.4.10.9911091604100.4027-100000@gemini.home.net>
References: <381B08B8.7FE96AFA@cygnus.co.uk>
X-SW-Source: 1999-11/msg00030.html

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