When I try to allocate an object on the far heap, the compiler is happy…
cc -vdefault -4 -ml -o test test.cpp
(No errors)
but the linker is not…
Warning(1028): void far * far operator new( int unsigned ) is an undefined
reference
Warning(1028): void far operator delete []( void far * ) is an undefined
reference
file test.o(test.cpp): undefined symbol void far * far operator new( int
unsigned )
file test.o(test.cpp): undefined symbol void far operator delete []( void
far * )
The docs advise that only “flat” and “small” 32-bit memory models are
available, and
both have:
code model = small
data model = small
default code pointer = near
default data pointer = near
Even if I specify the “Large” memory model to the compiler, the linker uses
“qnx flat”.
How do I instruct the linker to accept a Mixed 32-bit memory model?
“Gordon Freeman” <gf@bigfoot.com> wrote in message
news:cp4tbu$p5a$1@inn.qnx.com…
When I try to allocate an object on the far heap, the compiler is happy…
cc -vdefault -4 -ml -o test test.cpp
(No errors)
but the linker is not…
You are compiling in 32 bit mode (-4) hence far pointer are useless since
all pointer are 32 bits. Well not quite. according to the doc, far pointers
in 32 mode bits are actualy 48bits although I’m not sure what are the effect
of having 48 bits pointer. There is no such thing as a far heap, which is
why under C++ the new/delete operator that are returning far pointer do not
exists and the linker is complaining.
Warning(1028): void far * far operator new( int unsigned ) is an undefined
reference
Warning(1028): void far operator delete []( void far * ) is an undefined
reference
file test.o(test.cpp): undefined symbol void far * far operator new( int
unsigned )
file test.o(test.cpp): undefined symbol void far operator delete []( void
far * )
The docs advise that only “flat” and “small” 32-bit memory models are
available, and both have:
Under 32-bit all pointers are far (i
code model = small
data model = small
default code pointer = near
default data pointer = near
Well not really, 32 bit pointers are near. It’s the definition of far and
near that changes depending on the model. In 16 bit mode a near pointer
points to 64k block in the data segment, far pointer allow to point to any
segment of 64k. In 32 bit, near pointer can access 4Gig block in the data
segment… far pointers allow to point to any segment of 4Gig…
Even if I specify the “Large” memory model to the compiler, the linker
uses
“qnx flat”.
In 32 bit mode large doesn’t exists.
How do I instruct the linker to accept a Mixed 32-bit memory model?
There is no such think in 32bit mode, you have to forget everything you know
about 16 bit mode 
Mario Charest <nowheretobefound@8thdimension.com> wrote:
MC > “Gordon Freeman” <gf@bigfoot.com> wrote in message
How do I instruct the linker to accept a Mixed 32-bit memory model?
MC > There is no such think in 32bit mode, you have to forget everything you know
MC > about 16 bit mode
Mario, I don’t think this is exactly true. I don’t think that QNX has
libraries to support 32 bit mode large memory modle. But you can
certainly write your own asm code to use it.
The question would be, why would you want to use it?
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:cp75o3$hng$1@inn.qnx.com…
Mario Charest <> nowheretobefound@8thdimension.com> > wrote:
MC > “Gordon Freeman” <> gf@bigfoot.com> > wrote in message
How do I instruct the linker to accept a Mixed 32-bit memory model?
MC > There is no such think in 32bit mode, you have to forget everything
you know
MC > about 16 bit mode >
The question would be, why would you want to use it?
I am writing a “stress” utility to consume system memory, to observe how
gracefully/ungracefully application software responds to low memory
resources.
When I compile and run using small/flat memory models (near pointers by
default),
I find that I can consume system memory, no problem.
But memory that has been freed isn’t released back to the operating system
until the program exits. I thought that behaviour might change when using
“far” pointers to data instead.
Would it make any difference, or can memory be released to the OS
under software control?
-GF
Gordon Freeman wrote:
But memory that has been freed isn’t released back to the operating system
until the program exits. I thought that behaviour might change when using
“far” pointers to data instead.
That is a property of the malloc/free implementation, which does not
return memory from the heap to the OS at free() - it remains available
to satisfy any future malloc() from the process without OS involvement.
Would it make any difference, or can memory be released to the OS
under software control?
You could consume/release memory directly with mmap() and munmap() in
order to release it back to the OS. Try something like:
ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_ANON, NOFD, 0);
munmap(ptr, 4096);
to take/return 4k …
John Garvey wrote:
Gordon Freeman wrote:
But memory that has been freed isn’t released back to the operating
system
until the program exits. I thought that behaviour might change when
using
“far” pointers to data instead.
That is a property of the malloc/free implementation, which does not
return memory from the heap to the OS at free() - it remains available
to satisfy any future malloc() from the process without OS involvement.
Would it make any difference, or can memory be released to the OS
under software control?
You could consume/release memory directly with mmap() and munmap() in
order to release it back to the OS. Try something like:
ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_ANON, NOFD, 0);
munmap(ptr, 4096);
to take/return 4k …
There is also a malloc implementation in QUICS which is implemented via
mmap().
ftp://ftp.qnx.com/usr/free/qnx4/os/libs/libmalloc3r.tgz
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“John Garvey” <jgarvey@qnx.com> wrote in message
news:cp7cv6$n6m$1@inn.qnx.com…
You could consume/release memory directly with mmap() and munmap() in
order to release it back to the OS. Try something like:
ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_ANON, NOFD, 0);
munmap(ptr, 4096);
to take/return 4k …
MMmmmm, I tried this:
int fd;
char *addr;
char name[32];
fd = shm_open (name, O_CREAT, 0777);
addr = (char *)mmap (NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0L);
Tested the results (shm_open succeeded, returning valid fd), and got this
error info:
mmap failed: No such device or address
errno ENXIO: The length or offset argument is invalid for this file
descriptor.
Not sure what the problem could be, because 4096 is not an unreasonable
size, and offset=0.
-GF
Gordon Freeman wrote:
“John Garvey” <> jgarvey@qnx.com> > wrote in message
news:cp7cv6$n6m$> 1@inn.qnx.com> …
You could consume/release memory directly with mmap() and munmap() in
order to release it back to the OS. Try something like:
ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_ANON, NOFD, 0);
munmap(ptr, 4096);
to take/return 4k …
MMmmmm, I tried this:
int fd;
char *addr;
char name[32];
fd = shm_open (name, O_CREAT, 0777);
addr = (char *)mmap (NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0L);
Tested the results (shm_open succeeded, returning valid fd), and got this
error info:
mmap failed: No such device or address
errno ENXIO: The length or offset argument is invalid for this file
descriptor.
Not sure what the problem could be, because 4096 is not an unreasonable
size, and offset=0.
You’ve created a zero length object, and asked to map it. Check out the
technote in /etc/readme/technotes/shmem.txt for examples of this type of
activity.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“Adam Mallory” <amallory@qnx.com> wrote in message
news:cp9mm1$fnt$1@inn.qnx.com…
You’ve created a zero length object, and asked to map it. Check out the
technote in /etc/readme/technotes/shmem.txt for examples of this type of
activity.
“ltrunc” was missing. Without it, the sample program in “shmem.txt” fails
with
the same error message that I had been experiencing earlier.
Thank you all for your help. (I learned a lot in the process.)
\
“Gordon Freeman” <gf@bigfoot.com> wrote in message
news:cpa18n$n9q$1@inn.qnx.com…
“Adam Mallory” <> amallory@qnx.com> > wrote in message
news:cp9mm1$fnt$> 1@inn.qnx.com> …
You’ve created a zero length object, and asked to map it. Check out the
technote in /etc/readme/technotes/shmem.txt for examples of this type of
activity.
“ltrunc” was missing. Without it, the sample program in “shmem.txt” fails
with
the same error message that I had been experiencing earlier.
You could also use vdir. It’s a ram disk that can dynamicaly grow its size.
Just write a file in it and append data until out of ram.
Thank you all for your help. (I learned a lot in the process.)
\