Hi,
The first address 0xb6000000 is a physical memory 32-bit address that
we are trying to map under n32 or o32 and it is valid.
mmh = open("/dev/mem", O_RDWR | O_SYNC);
if (mmh < 0) {
.....
}
mmptr = (unsigned short *)mmap((void *)0, 0x1000,
PROT_READ | PROT_WRITE, MAP_SHARED,
mmh, 0xb6000000);
...
and the second one 0xffffffffb6000000 address is that old_mmap have
got on the kernel side when we do mmap under those abis, calling
do_mmap2 after that with 0xffffffffb6000000 last parameter. This
example above works correctly only under n64 abi.
thanks, Dinar.
On Fri, Sep 19, 2008 at 4:33 PM, Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> wrote:
> On Fri, 19 Sep 2008, Dinar Temirbulatov wrote:
>
>> I noticed that mmap is not working properly under n32, o32 abis in
>> MIPS64, for example if we want to map 0xb6000000 address to the
>> userland under those abis we call mmap and because the last argument
>> in old_mmap is off_t and this type is 64-bits wide for MIPS64, we end
>> up having for example 0xffffffffb6000000 address value. I am sure that
>> this is not a glibc issue. Following patch adds 32-bit version of mmap
>> and also it adds mmap64 support for n32 abi since mmap64 was
>> implemented correctly for n32 too.
>
> Well, neither with the o32 nor with the n32 ABI are 0xb6000000 or
> 0xffffffffb6000000 (which is the n32's equivalent of the former) valid
> user addresses, so your concern is?
>
> Maciej
>
