Do you have any clue (rough) on the amount of effort this change would cost? About the limited gain we can discuss: if you have a large application that has been created assuming 32bit and it needs to be ported to a 64bit architecture, I think the effort can be huge and the risk for forgetting things is high. It will be very hard to check whether the system behaves well under all conditions. --- Ronny On Wed, Oct 10, 2012 at 10:07 AM, Ralf Baechle <ralf@xxxxxxxxxxxxxx> 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. > > Also there's limited gain and even more limited time to implement things ... > > Ralf
