linux-mips
[Top] [All Lists]

Re: mmap is broken for MIPS64 n32 and o32 abis

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: mmap is broken for MIPS64 n32 and o32 abis
From: "Dinar Temirbulatov" <dtemirbulatov@gmail.com>
Date: Sun, 21 Sep 2008 14:55:26 +0400
Cc: linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Jj1XYucARUJS3q7uPknpC9Qhabf46LKAyRnk1rT8IfE=; b=C1UjDHge9+HBJ2CbgJn8brEKBiTamW4otN7R0RXZWpxTH+pnYfdy7qkLVxUzBZ6cDG iP/93l90dvCyy5SM3o6IZLwq25LI3SBHOLC7CZ9hyU2GyCj7iyvIbWeK7ZxX5mUkYpOi VYKkvV83Kwt+PN6kGfGZm4gbSmMTiRcK+OS/4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=AultqCmX+6xcUO0M9h+cORitdDzmbbjmTJt55sGD8WWw91MdA89iKEQBCNd+6dHInS a2rs1eo1Yn/6/bhKjdo4qBW7kXzcStnoLdiLeT9WZjwfEKN8NXe9f6RkF9AYFgSKE7mA VVZbnXRg7prG3GkuVjQEJ6hdHtcms55v/iVaY=
In-reply-to: <Pine.LNX.4.55.0809191803390.29711@cliff.in.clinika.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <a664af430809182331i41c9e344w83ecb2830ac24@mail.gmail.com> <Pine.LNX.4.55.0809191329080.29711@cliff.in.clinika.pl> <a664af430809190953k486e2012hf3a09caa50c9574a@mail.gmail.com> <Pine.LNX.4.55.0809191803390.29711@cliff.in.clinika.pl>
Sender: linux-mips-bounce@linux-mips.org
hi, Maciej
I don't think it has anything to do type definition of signed or
unsigned. I think following things happened here we called mmap() from
n32 and as it is defined is the glibc for this abi the sixth parameter
should be 32-bit wide integer and we transefed this 32-bit
value(0xb6000000) in the a5(r9) register according to the mips abi,
but we loaded this value with "lui     a5,0xb600" instruction and that
resulted with 0xffffffffb6000000 in the 64-bit version of a5
register(for 32-bit it is legitimate 0xb6000000). after that on the
kernel side we have this function old_mmap() and sixth argument there
is 64-bit wide integer (off_t type) and it does not that we called
this function from 32-bit environment  and that is why there is
0xffffffffb6000000 value in the end, so 0xffffffff is trash. I think
that we need to have a separate mmap system call handler for 32-bit
abis, also we need to add mmap2 handler for n32 as we have it for o32.

thanks, Dinar.


On Fri, Sep 19, 2008 at 9:25 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote:
> On Fri, 19 Sep 2008, Dinar Temirbulatov wrote:
>
>>          mmptr = (unsigned short *)mmap((void *)0, 0x1000,
>>                              PROT_READ | PROT_WRITE, MAP_SHARED,
>>                              mmh, 0xb6000000);
>
>  Ah, so it is the file offset you are concerned about.  Fair enough then.
> Obviously the non-LFS 32-bit variation has to sign-extend the offset as
> this is how the off_t type has been defined in this case, though it is
> interesting to note that the kernel treats this argument as unsigned while
> the C library API defines it as signed and there is no range checking in
> between.  Hmm...
>
>  Maciej
>

<Prev in Thread] Current Thread [Next in Thread>