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
