[Efi332] RE: Using newlib

David Eicher sailors3
Fri Aug 19 04:16:11 UTC 2005


I think _sinit may run if we can get the _RENT structure set up right.
Apparently there is suppose to be a pointer called _impure_ptr which is
suppose to point to a _reent structure which is used to make all these
library routines reentrant. When I run printf the _impure_ptr is accessed
(actually right after printf calls vfprintf), the pointer value is read and
used by vfprintf. The pointer value is 0x40. So the code soon tries to read
a field of the _reent structure at location 0x40 which is flash memory and
all FFFFFFFs. So the _REENT data is invalid. It isn't long before vfprintf
crashes as a result of this. 

I'm not sure how the _impure_ptr gets initialized. Does anyone know? If I
can figure that out (next task), I can probably figure out what to change to
fix it.

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 17, 2005 7:49 PM
To: efi332 at diy-efi.org
Subject: RE: Using newlib (was: [Efi332] Building newlib/libgloss for
MPC555)

Hi Gunter,

New info, I discovered that CHECK_INIT(fp) is called in vfprintf_r so it is
getting executed a different way than I thought. The bad news, running it
did NOT result in executing __sinit( ). I believe it is because it got a bad
pointer or argument from localeconv( ). 

So., my current theory is that the problem with with the locale
setup/configure. For whatever reason, localeconv is not return a valid
argument, I'll have to check on why tomorrow night.

Thanks,

Dave


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

Hi David,

(have been out all day...)

On Mon, Aug 15, 2005 at 08:13:59PM -0700, David Eicher wrote:
> 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. 

It is fp which has the wrong value.

Did you initialize in any way stdin/stdout? 

No, I don't know precisely how to do that, but plain printf() expands
the call to vfprintf (_stdout_r (_REENT), fmt, ap);

So it has to do with _stdout_r, which actually is a macro defined in
newlib-1.13.0/newlib/libc/include/stdio.h

It uses a parameter _REENT, but I haven't found out where this is
defined, and where and how it is initialized. I strongly guess this is
the key for getting further.

It can be as easy, as the implicit fopen() call for stdout is missing,
but it also can be more. I have to bail out here.

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

See above. Parameter passing is part of the PowerPC-EABI specification.
I think I have that in form of a .pdf from some IBM website, I forgot. But
it is not essential at this point.

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





More information about the Efi332 mailing list