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

[David Eicher]

Making some progress. I've discovered that the __sfvwrite ( ) function
accepts as input two parameters (fp and uio) as shown in this code snippet.

_DEFUN(__sfvwrite, (fp, uio),
       register FILE *fp _AND
       register struct __suio *uio)

It appears in the code that one of the parameters is passed to the function
in register r3, which gets copied to r27. I put a breakpoint at the
beginning of __sfvwrite (which is in file fvwrite.c) and discovered that r3
is 0xFFFFFFFF at the beginning of execution. 

So..., that is more background on why __sfvwrite is crashing. I have not
been able to tell which parameter is passed in r3 yet (working on it). 

Does anyone have any idea which one of these parameters might be sensitive
to my configuration and build of newlib? Like gm pointed out earlier, this
is tested code so it must be something I've done wrong that is causing the
problem.

Thanks,

Dave

-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of David Eicher
Sent: Wednesday, August 10, 2005 5:04 AM
To: efi332 at diy-efi.org
Subject: RE: Using newlib (was: [Efi332] Building newlib/libgloss for
MPC555)

Hello,

This target code has an exception table in it, as soon as I get it working I
plan to burn into flash and will then have the table set up for future
debug, this is just the first awkward step....

Correct, no interrupts in libgloss.

CTR got loaded with a 0xFFFFFFFF from register r9. r9 got loaded with that
value from an instruction as follows:

LWZ r9, 36(r27)
OR r4, r26, r26
MTCTR r9
BCCTRL r20, r0

CRASH! It IS consistent, I used a breakpoint to get there quickly this time
and it did the same thing again. Yep, I'm sure the processor is not broke,
but I wonder if this instruction is properly formed, it appears to me it
should execute the instruction after BCCTRL because the LK bit is set.

BTW, r27 = 0xFFFFFFFF so that is why CTR gets a bad value. I'll look and see
why r27 gets the bad value.

Thanks a jillion for the help here,

Dave




-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Wednesday, August 10, 2005 12:50 AM
To: efi332 at diy-efi.org
Subject: Re: Using newlib (was: [Efi332] Building newlib/libgloss for
MPC555)

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...


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

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332