From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: gcc on linux Date: Mon, 7 Jun 1993 20:40:10 GMT
In article <C89EGr.IpC@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>That is very odd. Almost every program these days does dynamic memory
>allocation. I've fairly confident that at least libc 4.3.3 with g++
>2.3.3 the memory allocation routines work quite well. If they didn't
>then my ObjectBuilder port would fail, since it uses new, malloc,
>realloc, calloc, delete and free quite heavily.
It works quite well --- but it doesn't tolerate some things that BSD programs
like to do like malloc(0) (a wrapper is provided for this) and it won't let
you do things the original AT&T malloc was lenient about like accessing memory
immediately after it has been free()d.
My JNOS port does a truly HUGE number of malloc()s and free()s, because the
original source does (I've been trying to keep my changes to a minimum) and
automatic variables are a bit limited when each internal "thread" has a tiny
stack, in some cases 128 bytes or less. (Actually, the Linux port has a
minimum of 384K because of curses overhead --- any "thread" can conceivably
cause JNOS to block on a select(), and it does a refresh() beforehand --- and
curses seems to require a lot of stack space.)
>Inocrrect ones, on the other hand, do produce differing results and
>failure modes. A product like purify will help out on the sun, but
>I'm not aware of anything that is as picky about memory usage on
>Linux.
Linux won't be able to use anything like purify until a process can easily
unmap pages of its address space, or map non-contiguous pages within its
address space without using shared memory. It also won't be able to trap
page-zero accesses. :-(
++Brandon
-- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.orgIt's not too late to turn back from the "Gates" of Hell... Linux: the free 32-bit operating system, available NOW. Why waaaaaait for NT?