UNIXpc per-process VM limit (Was: Re: Swapping and wmgr)

[Brant Cheikes]

First, thanks to Michael Ditto and Alex Crain for clarifying the
per-process memory allocation and corresponding limits.  Now, a wee
quibble:

In article <1002 at umbc3.UMD.EDU> alex at umbc3.UMD.EDU (Alex S. Crain) writes:
[...]
>	There are ways to make this area bigger, if your strapped for memory,
>like using the shared libraries. shlib is always present in the user image,
>as read only text. [...]
>	Unfortunately, shlib loses with programs line emacs, because unexec()
>in the emacs code tries to relocate it, and shlib is not relocateable. Someone
>could, of course, teach unexec() about shlib...

I'm not quite sure what you mean by "not relocateable" here.  In fact,
if you apply dump(1) to a few of your favorite COFFs, you'll discover
that the .lib section has different [pv]addrs in each one.  There
seems to be a confusion between the location of the shlib in virtual
memory and the listed address of the .lib section in a COFF, the
latter of which is important to unexec.  I discovered thru hacking
undump (just posted to unix-pc.sources) that it's straightforward to
move the [pv]addrs of the .lib around in the COFF.  There's no reason
why unexec couldn't be patched to do the same.

Also, you say that "shlib is always present."  If so, why is the .lib
section needed in a COFF in order for that executable to use the
shlib?  If what you say is true, then it should be possible to link an
a.out with the shared lib, then strip off the .lib section without any
adverse effect, no?

-- 
Brant Cheikes
University of Pennsylvania
Department of Computer and Information Science
ARPA: brant at linc.cis.upenn.edu, UUCP: ...drexel!manta!brant