Using newlib (was: [Efi332] Building newlib/libgloss for MPC555)

[Gunter Magin]

Hi,

On Tue, Aug 09, 2005 at 08:05:21PM -0700, David Eicher wrote:
> Thanks for the thoughts! You?re correct, I?m running in RAM and there is no
> exception table loaded in Flash, so it is all 0xFFFFFFFFs. It looks like it
> went to 0x1000 and tried to execute the instruction there, the debugger
> printed ?illegal opcode ? 0xFFFFFFFF?. 

Under normal conditions, it's ok for the time being (yet another
hack to be fixed later) there is no exception table, when there are
no exceptions. However, there could be some cause for exceptions in
the (buggy - due to insufficient development environment) code, and
therefore you can get the type of crash Jeff described. In these cases
it makes sense to at least implement some kind of attraction gathering,
nonreturning stub as an exception handler, for example let the LED
blink nervously.

I presume your particular libgloss implementation for serial out 
does not use interrupts...

> I decided to try single stepping through printf to see what it does. It
> executed the following routines:
> 
>  
> 
> Printf
> 
> Vfprintf
> 
> Localeconv         (libc ? locale.o)
> 
> Vfprintf              (returned to vfprintf from localeconv)
> 
> Strlen
> 
> Vfprintf
> 
> Sfvwrite
> 
>  
> 
> In sfvwrite the program lost its mind. One instruction before the crash the
> debugger displayed the instruction that would be executed next as 
> 
> BCCTRL r20, r0             0x4E800421
> 
> When I hit step again, CRASH! The debugger displayed:
> 
> PC: FFFFFFFF    CR: 5DFF3FF9   MSR: 00003402
> LR: 00C0C118   XER: E000FC7F
> <FFFFFFFF>: UNKNOWN OPCODE

> The PC just before this crash was: 0x00C0C114 which contained the opcode
> 0x4E800421.

The main question is, why did the CTR register contain 0xffffffff? This
is the value that was pushed into the program counter by this lethal
BCCTR instruction. Only the disassembled instructions before 0xc0c114
can tell...

> So, what is up with this! I don?t know if my processor is broke 

In my experience this is almost never the case, once it got that far
after reset...

> or if this
> is a illegal form of the instruction, or what. I?m not sure where the code
> was headed next but was anxious to find out. 

svfwrite() in newlib-1.13/newlib/libc/stdtio/fvwrite.c is a myriad of if
() clauses for some different conditions, and I guess the CTR register
was used to implement jumps around some blocks...

> It took about 1 ? hours of
> single stepping to get to that point.

You should give the breakpoint mechanism another try, now that you know
where the crash happens.  Breakpoints didn't work the other day for a
valid reason: the code has never been reached. So no reason to believe
the debugger doesn't work.

gm