Date:	Mon, 25 Jan 1999 05:03:11 -0500 (EST)
From:	Michael Callahan <mjc AT rodagroup DOT com>
X-Sender:	mjc AT evelyn DOT smith DOT edu
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com, "Peter J. Braam" <braam AT cs DOT cmu DOT edu>
Subject:	Re: Coda has TCP/IP and annonymous mmap for DJGPP on W95
In-Reply-To:	<Pine.SUN.3.91.990125091351.6041B-100000@is>
Message-ID:	<Pine.SGI.3.94.990125030159.10768F-100000@evelyn.smith.edu>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

On Mon, 25 Jan 1999, Eli Zaretskii wrote:
> On Sun, 24 Jan 1999, Michael Callahan wrote:
> 
> > Hmm.  There are real Unices that support mmap() only for device-special
> > files (where it was used to support mapping the framebuffer in the X
> > server), so such autoconfig scripts are likely to come to grief already.
> 
> I didn't know that.  In that case, there's no real problem.
> 
> > Note again: using mmap requires you to use a different crt0.o.
> 
> Why is this needed?

1) The point of the whole exercise is to let a program allocate
swap-backed pages in a reasonably large address space.  The program must
be able to choose the address where it wants a page allocated, and it must
be OK for the program to have, say, 64 MB of virtual memory with only a
fraction of the pages having committed swap.  (I.e.: it is not a solution
to allocate a 64 MB block of memory and just use a part of it.)

2) The DPMI implementation in Windows 95, the target platform, does not
permit you to do this.  You can ask for a block of memory, but you can't
specify where it will land in your virtual address space.  You can't
reserve a block of virtual memory and then commit swap-backed pages
selectively within it.

3) The normal crt0 allocates a block of memory using DPMI, copies the
program text and data to it, clears to bss, sets up the stack, and jumps
to the start of the program.  Once the program text is located in a
DPMI-allocated block, the game is lost: there is no way to guarantee to
the program that it will be able to allocate memory at any particular
virtual address outside that pre-allocated block. 

4) Conclusion: crt0 should instead reserve a large block of virtual memory
(say, 64MB), commit pages selectively as necessary to copy the program
text, data, bss into it, and then let the program later commit more memory
within the pre-reserved virtual memory block.  This is possible using a
custom VxD: the crt0 code as well as the mmap() implementation makes calls
to the VxD to manipulate memory.

Incidentally, I now vaguely recall that DJGPP has a crt0 and a crt1.  I
can't remember which does the DPMI stuff--but whatever, the point is that
I modified whatever startup code is responsible for allocating the
protected-mode memory for the program. 

I also modified the library that gdb and gdbserver use to load a program
image to use the MMAP VxD.  gdbserver is a neat program, incidentally: I
could debug Venus using a gdb session running in xemacs on Linux (where I
had all my source, using DJGPP as a cross-compiler) connecting via TCP to
a gdbserver program running on W95.

Michael

- Raw text -