[PATCH] SPU use a 16 byte fpos_t

[Patrick Mansfield]

On Fri, Sep 07, 2007 at 12:57:39PM +0900, Kazunori Asayama wrote:
> Patrick Mansfield <patmans@us.ibm.com> wrote:
> > On Thu, Sep 06, 2007 at 10:28:15AM +0900, Kazunori Asayama wrote:
> > > Patrick Mansfield <patmans@us.ibm.com> wrote:
> > > > fpos_t is 12 bytes for 32 bit ppc glibc, and 16 bytes for 64 bit.
> > > > 
> > > > Currently SPU newlib uses 4 bytes for fpos_t. This is always a problem
> > > > with 64 bit ppc, since the fgetpos() assist call writes 8 bytes back for
> > > > the offset, and is a potential problem with 32 bit ppc.
> > > > 
> > > > So for SPU always use 16 bytes for fpos_t and also make currently unused
> > > > (in SPU) _fpos64_t 16 bytes.
> > > 
> > > Do you have any plan for off_t and size_t ?
> > > They have a similar problem to this one.
> > 
> > But they don't overwrite memory like this, since we pass in 32 bit values
> > for off_t and size_t, not the addresses of them.  And the return value for
> > lseek is truncated into a 32 bit value (in libspe).
> > 
> > So it does like there is a problem with lseek and off_t in getting
> > truncated return values, that needs a libspe fix. I think we should have
> > fix that, add new assist call interfaces to handle 64 bit values, and then
> > add large file support for SPU in newlib via the new assist call interfaces.
> 
> Do you mean that the newlib should provide both of LFS and non-LFS,
> and that applications should be able to switch between LFS and non-LFS
> (by _FILE_OFFSET_BITS?) as you said via the cbe-oss-dev ML before?

Yes, though I do not have a strong preference for it (versus always having
off_t be 64 bits), and don't think it adds much value - assuming anyone
writing optimal SPU code would handle IO on the PPU side, and use DMA's
to/from the SPU LS.

-- Patrick Mansfield