mmap problem with 6.2.1

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

dpr_ptr = mmap (0, ONE_MEG, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_PHYS, NOFD, buff [4]);//1
dpr_ptr = mmap_device_memory( 0, ONE_MEG, PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, buff [4] );//2
if (dpr_ptr == MAP_FAILED)
{
fprintf (stderr, “failed to map FPGA memory %x\n”, buff[4]);
perror(“MMAP”);
}

with 6.2.1, the mmap call in line //1 above fails, where it used to work with 6.2.0 and before.
(The error is Not enough memory.)
Replaced by line //2, the call succeeds.
(ONE_MEG being defined as (1024*1024)

Ironically, the example from the mmap helpviewer:
/* Map in VGA display memory */
addr = mmap( 0,
65536,
PROT_READ|PROT_WRITE,
MAP_PHYS|MAP_SHARED,
NOFD,
0xa0000 );
is exactly what line //1 is…

2

acellarius@yahoo.com wrote:

dpr_ptr = mmap (0, ONE_MEG, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_PHYS,
NOFD, buff [4]);//1
dpr_ptr = mmap_device_memory( 0, ONE_MEG, PROT_READ|PROT_WRITE|PROT_NOCACHE,
0, buff [4] );//2
if (dpr_ptr == MAP_FAILED)
{
fprintf (stderr, “failed to map FPGA memory %x\n”, buff[4]);
perror(“MMAP”);
}

There was a BIG kerfuffle about this.

The last parameter to mmap() is declared as an off_t – signed 32 bit
integer.

Your buff[4] is, I would almost guarantee, a value > 2G. Represented
as a signed value, this is a negative offset.

6.2.0 and earlier silently treated this as unsigned and worked.

6.2.1 said, hey, that’s an invalid value – better fail it.

post 6.2.1 will probably be changed to, once again, quietly handle
it as it used to behave.

Using mmap() on an out-of-range value was poor coding. (Especially
as the docs for mmap say “You should use mmap_device_memory()
instead of MAP_PHYS.” Still, the example shows it, and that
example should probably be removed, too.)

QSSL changing the behaviour without release noting it (at the
minimum) was bad.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

3

On Mon, 21 Apr 2003 17:35:05 GMT, acellarius@yahoo.com wrote:

dpr_ptr = mmap (0, ONE_MEG, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_PHYS, NOFD, buff [4]);//1
dpr_ptr = mmap_device_memory( 0, ONE_MEG, PROT_READ|PROT_WRITE|PROT_NOCACHE, 0, buff [4] );//2
if (dpr_ptr == MAP_FAILED)
{
fprintf (stderr, “failed to map FPGA memory %x\n”, buff[4]);
perror(“MMAP”);
}

with 6.2.1, the mmap call in line //1 above fails, where it used to work with 6.2.0 and before.
(The error is Not enough memory.)
Replaced by line //2, the call succeeds.
(ONE_MEG being defined as (1024*1024)

Ironically, the example from the mmap helpviewer:
/* Map in VGA display memory */
addr = mmap( 0,
65536,
PROT_READ|PROT_WRITE,
MAP_PHYS|MAP_SHARED,
NOFD,
0xa0000 );
is exactly what line //1 is…

After some browsing through that MMAP thread, I see my problem
is the same: the offset is 0xF4500000.
So previously it was ok as a 32 bit value (<=6.2.0), now it’s not.
This should be documented ASAP, and preferably mmap should continue
to work the way it used to.
IMO it’s not sensible to make the offset signed.

Anyway, offset_t is not documented.
which reminds me of another post where I asked where these
QNX types are defined. (and read the headers is not
the right answer).

4

acellarius@yahoo.com wrote:

Anyway, offset_t is not documented.
which reminds me of another post where I asked where these
QNX types are defined. (and read the headers is not
the right answer).

offset_t is NOT a QNX type. It is a POSIX type. (Take a look at
the lseek() call, for instance.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

5

David Gibbs <dagibbs@qnx.com> wrote:

acellarius@yahoo.com > wrote:

Anyway, offset_t is not documented.
which reminds me of another post where I asked where these
QNX types are defined. (and read the headers is not
the right answer).

offset_t is NOT a QNX type. It is a POSIX type. (Take a look at
the lseek() call, for instance.)

And POSIX/SUS states that off_t is a signed value.

You can get a list of types and thier values from opengroup.com.

http://www.opengroup.org/onlinepubs/007908799/xsh/datatypes.html

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

6

Chris McKillop <cdm@qnx.com> wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
acellarius@yahoo.com > wrote:

Anyway, offset_t is not documented.
which reminds me of another post where I asked where these
QNX types are defined. (and read the headers is not
the right answer).

offset_t is NOT a QNX type. It is a POSIX type. (Take a look at
the lseek() call, for instance.)


And POSIX/SUS states that off_t is a signed value.

And, you can figure it out, too, since you can do a SEEK_CUR
backwards from the current location:
SEEK_CUR
The new file position is computed relative to the current file position. The value of offset
may be positive, negative or zero.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

7

David Gibbs <dagibbs@qnx.com> wrote:

Chris McKillop <> cdm@qnx.com> > wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
acellarius@yahoo.com > wrote:

Anyway, offset_t is not documented.
which reminds me of another post where I asked where these
QNX types are defined. (and read the headers is not
the right answer).

offset_t is NOT a QNX type. It is a POSIX type. (Take a look at
the lseek() call, for instance.)


And POSIX/SUS states that off_t is a signed value.

And, you can figure it out, too, since you can do a SEEK_CUR
backwards from the current location:
SEEK_CUR
The new file position is computed relative to the current file position. The value of offset
may be positive, negative or zero.

signed is fine. but is it 32 bit or 64 bit? it may work fine on other Unix
with a 64 bit off_t.

8

liug <liug@mama.indstate.edu> wrote in message
news:b8acn2$mtr$1@inn.qnx.com…

signed is fine. but is it 32 bit or 64 bit? it may work fine on other Unix
with a 64 bit off_t.

It may work, but it’s still a bad assumption, nothing says it has to be
64bits (Solaris can have 32bits for example).

-Adam

9

liug <liug@mama.indstate.edu> wrote:
: signed is fine. but is it 32 bit or 64 bit? it may work fine on other Unix
: with a 64 bit off_t.

By default, off_t is a signed 32-bit type. If you define _FILE_OFFSETS_BITS
to be 64 when you compile your code, off_t becomes a signed 64-bit type. The
Programmer’s Guide mentions this briefly, but we’re adding this information
to the Library Reference as well.

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems