On Wed, Oct 10, 2012 at 10:07:56AM +0200, Ralf Baechle wrote:
> On Wed, Oct 10, 2012 at 08:32:47AM +0200, Ronny Meeus wrote:
>
> > I have a legacy application that we want to port to a MIPS (Cavium)
> > architecture from a PPC based one.
> > The board has 4GB memory of which we actually need almost 3GB in
> > application space. On the PPC this is no issue since the split
> > user/kernel is 3GB/1GB.
> > We have to use the N32 ABI Initial tests on MIPS showed me the
> > user-space limit of 2GB.
> > We do not want to port the application to a 64bit
> >
> > Now the question is: are there any workarounds, tricks existing to get
> > around this limitation?
> > I found some mailthreads on this subject (n32-big ABI -
> > http://gcc.gnu.org/ml/gcc/2011-02/msg00278.html,
> > http://elinux.org/images/1/1f/New-tricks-mips-linux.pdf) but is looks
> > like this is not accepted by the community. Is there any process
> > planned or made in this area?
>
> I think limited time and gain killed the propoosed ABI rather than
> theoretical issues raised. Other architectures such as i386 - well,
> IIRC any 32-bit ABI with more than 2GB userspace and a signed
> ptrdiff_t - are suffering from them as well.
There's no issue with ptrdiff_t being signed 32-bit as long as the
implementation does not allow individual objects larger than 2GB.
Taking differences between pointers into different objects is UB.
Rich
|