Re: mmap is broken for MIPS64 n32 and o32 abis

["Dinar Temirbulatov" <dtemirbulatov@gmail.com>]

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
>