From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25254 invoked by alias); 14 Apr 2005 10:44:17 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 24843 invoked from network); 14 Apr 2005 10:44:09 -0000 Received: from unknown (HELO pollux.ds.pg.gda.pl) (153.19.208.7) by sourceware.org with SMTP; 14 Apr 2005 10:44:09 -0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 63081E1C82; Thu, 14 Apr 2005 12:44:02 +0200 (CEST) Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07100-10; Thu, 14 Apr 2005 12:44:02 +0200 (CEST) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 002BFE1C77; Thu, 14 Apr 2005 12:44:02 +0200 (CEST) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.1/8.13.1) with ESMTP id j3EAi3lB010815; Thu, 14 Apr 2005 12:44:03 +0200 Date: Thu, 14 Apr 2005 10:44:00 -0000 From: "Maciej W. Rozycki" To: Richard Henderson Cc: Mark Kettenis , echristo@redhat.com, binutils@sourceware.org Subject: Re: [RFA] Update OpenBSD/mips64 support In-Reply-To: <20050414012436.GA1150@redhat.com> Message-ID: References: <200504132213.j3DMDp4H019946@elgar.sibelius.xs4all.nl> <1113431453.4591.7.camel@localhost.localdomain> <200504132237.j3DMbnCm005343@elgar.sibelius.xs4all.nl> <1113431956.4591.10.camel@localhost.localdomain> <200504132248.j3DMmU9A016212@elgar.sibelius.xs4all.nl> <20050414012436.GA1150@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Status: Clean X-SW-Source: 2005-04/txt/msg00368.txt.bz2 On Wed, 13 Apr 2005, Richard Henderson wrote: > I wouldn't say that. Think of it as merely a 64-bit application that > Just So Happens to only use the low 31 bits. > > The only thing the kernel needs to do is for mmap (0, ...) choose an > address in the low 32 bits. For everything else, the application will > provide a correct value or its broken and will suffer the consequences. Well, that's the kernel part. There's userland as well -- and welcome to the world of LFS: -EFBIG and unmappable files... Maciej