Mail Archives: djgpp-workers/2000/05/09/11:06:44
Bonjour
>
> > > Note that ggc-page also uses /dev/zero, which djgpp doesn't have.
> >
> > This should be easy to provide via an FSEXT. If the code is private
> > to GCC sources, none of the complications with using FSEXT in the
> > library apply.
>
> Cygwin has /dev/zero, and it fails anyway. I suspect there's some
> subtle functionality in /dev/zero that I didn't emulate right. If we
> add /dev/zero to djgpp, it needs to be tested well, and it needs to
> work *right* or it will cause subtle problems.
>
> > > Or, it needs to be able to map anonymous pages, which may also be
> > > hard with DJGPP.
> >
> > Does that "Or" mean that if /dev/zero is available, mapping anonymous
> > pages is not required? Or does gcc-page require mapping in any case?
>
> It means I don't know. I just saw separate conditionals for those
> cases.
Many ways to provide anonymous mapping :
#ifdef MAP_ANON
cp = mmap(0, nbytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
#else
{
int fd = open("/dev/zero", O_RDWR);
cp = mmap(0, nbytes, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);
}
#endif
I beleive MAP_ANON, is more BSDish. The "/dev/zero" is more SVR4ish.
Both are provided on GNU/Linux ... I think, the
relevant bits are in /usr/include/sys/mman.h
Unix98 does not say anything about MAP_ANON, did not check POSIX.
"/dev/zero" is there to zeroed the new allocated space. Which
leads to amusing dependencies when doing a chroot().
It should be also possible to have a minimal mmap() for files
by reading the file incore.
mlock() and friends would be noops ? since it is there
to protect against other processes. Unless there is
a way in DOS to proctect/lock certain parts of the memory.
int mlock(const void *, size_t);
int mlockall(int);
void *mmap(void *, size_t, int, int, int, off_t);
int mprotect(void *, size_t, int);
int msync(void *, size_t, int);
int munlock(const void *, size_t);
int munlockall(void);
int munmap(void *, size_t);
int shm_open(const char *, int, mode_t);
int shm_unlink(const char *);
At the top of my head, I remember many applications on Un*x
use mmap() to grab some memory and maintain there own pool,
They usually do that for example to provide garbage collection
or they manage the memory more efficiently then the default
allocator. So they do stuff like :
void *malloc (size_t size)
{
....
mmap (...);
....
}
Meaning if the mmap() implementation on DJGPP is
mmap (...)
{
calloc (...)
}
It can lead to problems, should probably be something like
mmap ( .. )
{
__djgpp_malloc (..);
}
This is probably too obvious.
Was not there a VFS lib for DJGPP at one point ?
--
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!
- Raw text -