[pups] Maximum PDP-11 executable size?

Steven M. Schultz sms at moe.2bsd.com
Fri Apr 20 09:47:22 AEST 2001


Hi -

> From: Edward Brocklesby <ejb at leguin.org.uk>
> I'm having problems compiling some large-ish programs on 2.11BSD, for example 
> MH. Even when putting *everything* on overlays, I still get an error:

	It has been eons and eons since I attempted MH and I can't remember
	if I gave up or finally got something to work (shows how long its
	been ;)).

> [ejb at styx] ~/mh-6.8.4.orig/uip > /bin/ld -i -X -o xforw /lib/crt0.o -Z forw.o 
> -Z whatnowproc.o -Z whatnowsbr.o -Z sendsbr.o -Z annosbr.o -Z distsbr.o -Z 
> ../config/config.o -Z ../sbr/libmh.a -Z ../mts/libmts.a -Z ../zotnet/libzot.a 
> -Z -lc -Z -lerrlst -Z ../config/version.o
> ld: too big for type 431 (problem 2: tsize = 0, ovrnd = 8192, dtotal = 0)
> [ejb at styx] ~/mh-6.8.4.orig/uip >

	Hmmm, I grep'd the current source to 'ld' and couldn't find the
	message "problem 2: ...".   I do remember that being present during
	the debugging of 'ld' when the long symbol names (the "string table"
	aka 4.3BSD a.out format) capability was being developed.

	That suggests that 'ld' might be out of date.

	The answer to the 'Maximum PDP-11 executable size?' question is fairly
	length and a bit involved ;).   Assuming split I/D:

	  Short answer: 120KB to 904KB

	Long answer:

	without overlays there is one 64KB code segment and one 56KB data
	segment giving 120KB for a non overlaid program.  In practice if a
	program hits 56KB out of 'ld' then there's no room for malloc() and
	the program may link but it won't run ;(

	For overlaid programs there is still but one 56KB data segment (the top
	8KB is for the stack) but now the code can be arranged differently:

	There is a maximum of 15 overlays and there can be no 'gaps' (zero
	length/empty overlays between populated overlays).

	BASE	OVERLAYSIZE	TOTALTEXT
	8KB	56KB * 15	840KB
	16KB	48KB * 15	736KB
	24KB	40KB * 15	624KB
	32KB	32KB * 15	512KB
	40KB	24KB * 15	400KB
	48KB	16KB * 15	288KB
	56KB	8KB  * 15	176KB

	In reality the kernel probably would choke on the first several cases,
	and even if it didn't that large of a program would cause severe 
	swapping.

	Most overlaid programs on the system ('vi' for example) use either the
	base=48KB or base=56KB layout.  I think 'kermit' might use the 40KB
	base segment.

	The "tsize" error would indicate that the code size summing had an
	overflow - that was a bug at one time and was later fixed, which 
	again suggests that the 'ld' is out dated somehow.

	If 'ld' was able to create 'xforw' try doing a "size xforw" on it
	and seeing how far it got - perhaps a clue can be gathered that
	way.

	You may need to usually terminate the overlay list with a -Y - I don't
	believe it's "required" though.

	-Z -lc -Z -lerrlst -Y ../config/version.o

> is there any way around this, or is MH just too big to fix on a PDP?

	Couple things to try.  Use 'size' on the .o (and/or .a) files to
	see how big things are - add them up and see if things start overflowing
	16 bits.   There was an overflow bug in ld's size computations - it was
	fixed by using a 'long' in a couple places to detect wraparound. 

	What version of 2.11 (should be in the first couple lines of /VERSION)
	are you using?   Sure feels like 'ld' is old and having problems that
	were fixed later on.

	Steven Schultz
	sms at to.gd-es.com


Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id KAA57165
	for pups-liszt; Fri, 20 Apr 2001 10:57:13 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)


More information about the TUHS mailing list