This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SPU missing some stdio functions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]