[pups] Maximum PDP-11 executable size?

[Steven M. Schultz]

Hi -

> > 	message "problem 2: ...".   I do remember that being present during
> 
> That's something I added myself, to try to help with the problem..

	Ok - whew, for a minute there I thought some of my debug code had
	leaked to the world ;)   That's the style of debug message I use <g>

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

	Ouch - that is a bit old, there are updates thru 434 (I've 435 in
	midstream but haven't had time to finish it).

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

	Ah.   Much becomes clear now.   That indeed was the version at one time.
	A year or so ago I and Warren coordinated an update to the 2.11 in PUPS
	The current PUPS version is 431 (only 3 updates since then - I've
	slowed down a lot over the last couple years).

> hm.. how do you specify the base segment size to ld? i don't see anything in 

	You don't.   At least not directly.  Anything outside an overlay
	goes into the base segment.  Thus anything before the first -Z goes
	into the base, and anything after the -Y goes into the base.

> the manual page. Just link enough code into the base that it becomes the 
> right size?

	That's basically the way to do it.  You can do "size" on the .o files
	first to get an idea what you want to put where but after that tuning
	the overlays to fit is a bit of an art.

> text    data    bss     dec     hex
> 27648   35860   32412   95920   176b0   total text: 83072
>         overlays: 832,4352,2624,832,1920,29568,192,11008,4096
	
	the single BIGGEST problem is that 'data + bss' exceeds not only the
	56KB limit but the total 64KB limit available to a process.  Looks
	like MH want 35860+32412 or 68272 bytes of D space.

	You might be able to get the code to fit - I'd pack the base to at
	least 40KB (more likely 48KB) and only have two or three overlays
	of 24KB or 16KB.

	THe data space problem means you're going to have to go and lower
	a lot of the buffer size limits.   Remember:  even if you do get
	the dataspace down to where the linker doesn't complain the program
	will almost certainly try to malloc() memory.  Thus the smaller the
	data+bss the better - and be prepared for malloc() failures

	One thing that can be done is to run 'xstr' over the sources and
	collect error message strings, printf strings, and so on into a common
	pool.   The other thing that can be done is create a strings file
	and extract as many as possible strings from the source modules into
	an external file.   Examples of doing this type of thing can be found
	in the source tree - 'lint' was one such program, 'sendmail' was another
	and kermit yet another (that's why there are 'sendmail.sr'  and
	'kermit5.sr' files on the system).

	In fact 'kermit' is a good example of squishing a monster program into
	a small machine.  Check out /usr/src/new/kermit5.188

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

	Hmmm, could be.  

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

	The size of the .a doesn't accurately reflect the code+text+bss

	For one thing 'bss' takes up no room at all in an archive.   Don't
	forget that symbol tables and relocation information (as well as
	'ar' book keeping info) is present.   You can't rely on "ls -l"
	to say very much about an object file - only "size" can do that.
	"size libmh.a" will give a much better idea where the problem areas
	are.

	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 OAA58045
	for pups-liszt; Fri, 20 Apr 2001 14:21:45 +1000 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)