[pups] Maximum PDP-11 executable size?

[Edward Brocklesby]

On Friday 20 April 2001 12:47 am, Steven M. Schultz wrote:
> > [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

That's something I added myself, to try to help with the problem..

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

/VERSION says:
Current Patch Level: 400
Date: January 24, 1998

That's what was on the PUPS FTP site..

> 	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.

hm.. how do you specify the base segment size to ld? i don't see anything in 
the manual page. Just link enough code into the base that it becomes the 
right size?

> 	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.

possibly, i will look on the 2BSD patch archives now..

> 	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.

text    data    bss     dec     hex
27648   35860   32412   95920   176b0   total text: 83072
        overlays: 832,4352,2624,832,1920,29568,192,11008,4096

this particular link gave the error:
ld: too big for type 431 (problem 2: tsize = 0, ovrnd = -32768, dtotal = 0)

the negative ovrnd i find very strange- perhaps the wrapround bug?

> 	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

nope.. this doesn't seem to help

> > 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.

Well, considering that there's a couple of *large* libraries here..
-rw-r--r--  1 ejb        127074 Apr  9 14:47 ../zotnet/libzot.a
-rw-r--r--  1 ejb        102126 Apr  9 14:39 ../sbr/libmh.a

maybe that's the problem..

	-larne-

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