Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!njin!princeton!udel!burdvax!bpa!cbmvax!vu-vlsi!cgh!manta!brant From: brant@manta.UUCP (Brant Cheikes) Newsgroups: comp.sys.att Subject: Re: UNIXpc per-process VM limit (Was: Re: Swapping and wmgr) Message-ID: <369@manta.UUCP> Date: 2 Jun 88 14:00:37 GMT References: <3030@crash.cts.com> <365@manta.UUCP> <1002@umbc3.UMD.EDU> Reply-To: brant@manta.UUCP (Brant Cheikes) Organization: Soul of the Gnu Machine, Philadelphia Lines: 34 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@umbc3.UMD.EDU> alex@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@linc.cis.upenn.edu, UUCP: ...drexel!manta!brant