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@xxxxxxxxxxxxxx> 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 >
