jjo@calmasd.GE.COM (Jay Olson) (06/25/87)
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? Thanks in advance for any information. Jay Olson a consultant to GE Calma, San Diego, CA ...sdcsvax!calmasd!jjo jjo@calmasd.GE.COM
mats@forbrk.UUCP (Mats Wichmann) (06/30/87)
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
mash@mips.UUCP (John Mashey) (07/09/87)
In article <349@forbrk.UUCP> mats@forbrk.UUCP (Mats Wichmann) writes: >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? 1) In general, UNIX linkers haven't had to face really large executables, and they tend to break, whether by actual sizes, or numbers or relocation entries, or symbol table entries, etc. In particular, if you take some of the typical codes that have existed for years on big CDC machines and try to put them on typical micro UNIXes, bad things happen. 2) Virtual memory image sizes need pushing also; I don't know how much is enough. I do know 32MB of code and 128MB of data ISN'T enough! -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086