Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ptsfa!dual!forbrk!mats
From: mats@forbrk.UUCP (Mats Wichmann)
Newsgroups: comp.unix.wizards
Subject: Re: Questions about max size of text segment
Message-ID: <349@forbrk.UUCP>
Date: Tue, 30-Jun-87 10:08:16 EDT
Article-I.D.: forbrk.349
Posted: Tue Jun 30 10:08:16 1987
Date-Received: Sat, 11-Jul-87 01:43:20 EDT
References: <2294@calmasd.GE.COM>
Reply-To: mats@forbrk.UUCP (Mats Wichmann)
Distribution: world
Organization: Fortune Systems / SCI Technology  (Berkeley, CA)
Lines: 60

In article <2294@calmasd.GE.COM> jjo@calmasd.UUCP (Jay Olson) writes:
>Can anyone shed some light on the factors affecting the maximum size of
>the text segment on various versions of Unix, particularly Ultrix and
>Sun Unix?
>
>Empirically, it appears that the limit is around 7.5 Mb on Sun Unix 3.2.
>Interestingly, there is a range of text segment sizes where ld will
>produce an output file which cannot sucessfully be executed. Above some
>threshold size, ld won't even produce an output file. I have reason to
>believe that this behavior also happens under Ultrix 1.2, but I don't
>have enough disk space at the moment to find out.
>
>Is the maximum size of the text segment typically hardwired into the
>kernel, or can it be configured?
>

A "maximum" size for the text segment is a side effect of the memory
management implementation in the kernel - sometimes there is a
limit imposed by the hardware; the software implementation may
be such that this is changed (reduced), or the software may impose
a limit where there effectively is none except "size of the virtual
address space" as far as hardware is concerned. Unless the limit
is imposed to take advantage of some efficiency in keeping segments
below a certain size it is extremely unlikely that this could be
a configurable parameter.

To give some examples, the Fortune 32:16 is an M68000 processor with
a simple 4-segment base-and-limit MMU. These segments are assigned
as text-data-stack-other (other is used for shared memory in our sVr2).
Because the hardware uses some of the 24 address bits for other
purposes, the maximum size of each of the segments is 0x200000, or
2 Meg (this can be considered pretty much hardware-imposed). 
The Fortune Formula is an M68020 processor with an M68851 MMU, which 
provides support for paging. However, to ease the burden of changing 
an already non-standard version of UNIX, Fortune's For:Pro (which is 
a v7/4.1/sIII amalgam with lots of local hacks, er, enhancements) was 
done as a segmented system similar to the 32:16, but with larger 
segments; it has a maximum segment size of 32 Meg - this limit being
completely arbitrary choice of the software implementation.
Both of these systems, being segmented, swapping systems, are further
limited by the amount of physical memory (and, in For:Pro, by a 
tunable variable which constrains the maximum size of a user process).

In our sVr3 port to the Formula, there is a virtual address space of 
about 450 Meg available, which can be assigned as necessary to each
of text, data, and stack, although the greatest efficiency can
be obtained when no segment is greater than 2 Meg. Again, the 450
meg is a limitation imposed by the choices in our software memory 
management implementation. The virtual address space could have
been bigger, but the cost would have been an extra level of page
table lookup, which was not a difficult choice to make.

As to the ld issues, I can't shed any light on a specific implementation,
but ld should not grumble unless it is asked to exceed a built-in limit;
it is possible that someone has not got the kernel's limit quite in
sync with the loader's limit, which is not totally shocking, since
the C compiler package is probably designed to run on a range of
different machines.

Mats Wichmann