This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: SPU missing some stdio functions
- From: Kazunori Asayama <asayama at sm dot sony dot co dot jp>
- To: patmans at us dot ibm dot com
- Cc: newlib at sourceware dot org, SALIU at de dot ibm dot com
- Date: Wed, 09 May 2007 00:07:57 +0900 (LDT)
- Subject: Re: SPU missing some stdio functions
- References: <20070507234523.GA4052@us.ibm.com>
Patrick Mansfield <patmans@us.ibm.com> wrote:
> Since we switched SPU over to not build anything under newlib/libc/stdio,
> we are now missing several functions that were previously built.
>
> I have not done a complete audit yet [kind of a pita, some functions under
> newlib/libc/stdio won't compile because SPU has its own __FILE, and so I
> can't easily compare libc.a content with and without newlib/libc/stdio
> built; we also have the special SPU integer printf setup].
>
> But so far, compared to before the change, I have found we no longer build
> or have these functions (under newlib/libc/stdio) available on SPU:
>
> fseeko
> ftello
> getdelim
> getline
> getc_unlocked
> mktemp
> mkstemp
> putc_unlocked
>
> Sa was trying to run some compiler tests, and had failures because of the
> missing mkstemp.
>
> Of course newlib usage of missing functions will also lead to link time
> failures (of the above list, only mkstemp is referenced in newlib via
> hash_page code).
I see.
>
> Should we move back to an override setup for newlib/libc/stdio files?
I don't prefer this approach.
I think that it is difficult to do so because of SPE specific FILE
definition as you are saying. We may be able to build
newlib/libc/stdio by using the common __FILE instead of SPE's FILE,
however, I think that that can cause potential bugs,
e.g. inconsistency of FILEs between SPE and PPE, etc.
>
> Or???
>
> More analysis needed, but note:
>
> ftello() can just call ftell() but SPU needs a ftell_r(), similar for
> fseeko().
>
> mktemp() and mkstemp() are good canidates for assisted calls.
>
> getline() just calls getdelim(). getdelim() looks like it might work OK as an
> assisted call, not sure what getc_unlocked usage implies,
>
> I don't know about getc/putc_unlocked(), especially given the SPU context
> model (a linux thread holds the SPU context).
>
> We should get libspe (any of the above) updated with any new assisted
> calls before putting them in newlib.
These alternatives sound better.
Here are my minor comments:
- "C/C++ language extensions for CBEA" (section "SPU C and C++
Standard Libraries and Language Support") says that 'printf' (for
'printf debugging') is the only stdio function to be provided. So I
don't think that we must provide a complete set of newlib's stdio.
- I don't understand the reason why ftell_r() is required for
SPU. Isn't ftell() sufficient for SPU's ftello() ?
- I suppose getline() and/or getdelim() are difficult to offload,
because a buffer must be allocated by callee when no buffer is
provided by caller but length of the line is unpredictable. That is,
PPE must allocate a buffer on LS for the line, or... some kind of
special interaction between PPE and SPE will be needed.
- If we provide getc/putc_unlocked() (and
getchar_/putchar_unlocked()?), I think we also should provide
offloaded flockfile() and funlockfile() to lock FILEs on PPE side.
--
(ASAYAMA Kazunori
(asayama@sm.sony.co.jp))
t