Hi Dinar, > 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 Which is correct, as this is how 32-bit integers are represented by 64-bit MIPS platforms. > 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. The problem is you cannot represent the file offset of 3053453312 or 0x00000000b6000000 using the 32-bit interface. What you can represent is -1241513984 or 0xffffffffb6000000 and that is a valid offset for calls like lseek(), but not necessarily mmap() (though arguably we have a bug/feature in Linux where negative offsets are not explicitly checked for in mmap()). To represent 3053453312 or 0x00000000b6000000 correctly you need to use the 64-bit interface LFS calls provide. In this case that would be mmap64() or use _FILE_OFFSET_BITS as appropriate. Maciej
