*BSD News Article 62810


Return to BSD News archive

Newsgroups: comp.bugs.2bsd
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.eng.convex.com!newshost.convex.com!egsner!newshost.cyberramp.net!news.consultix.com!nntp.netrex.net!wlbr!sms
From: sms@wlv.iipo.gtegsc.com (Steven M. Schultz)
Subject: Re: ld failure while rebuild 2.11BSD kernel
Sender: news@wlbr.iipo.gtegsc.com (System Administrator)
Organization: GTE Government Systems
Message-ID: <Dn8tx9.7Br@wlbr.iipo.gtegsc.com>
Originator: sms@wlv.iipo.gtegsc.com
References: <4gh47t$nkv@hustle.rahul.net>
X-Nntp-Posting-Host: wlv.iipo.gtegsc.com
Date: Fri, 23 Feb 1996 04:47:23 GMT
Lines: 207

	Not sure if this made it out before one of the drive on the News
	system here crashed last night.

In article <4gh47t$nkv@hustle.rahul.net>, Bob Armstrong  <rla@rahul.net> wrote:
>  I am using a 11/73 running the as distributed GENERIC 2.11BSD system,
>and I'd like to build a new kernel.  So far I've tried to duplicate the
>GENERIC and NONET kernels using the configuration files distributed
>(this is just as a test to make sure I have all the parts I need to
>build my own customized kernel).  In each case everything compiles OK,
>but the link fails with:
>
>	ld: too big for type 431
>
>  Could someone interpret this message for me ?
>
>Thanks,
>Bob


	This may be of some help - I typed it up the last time the same
	question was asked.

	RSH (Real Soon Now;-)) this is going into the setup&installation
	documentation - I just haven't gotten around to it (a 'round tuit'?)
	yet.

	Steven Schultz
	sms@moe.2bsd.com or sms@wlv.iipo.gtegsc.com
------------------
> The Makefile proceeds without errors until the final (massive) link run.
> Then it says:
>                         too big for type 431
> and exits code 2.
> I tried playing with Makefile, deleted some modules, like the rk, which
> I do not have, and moved a couple around. Same result.
> Obviously I'm new at this. Any assistance appreciated.

	This is not unexpected.  In fact I was placing bets with myself
	as to when the first person would encounter the 'too big' message ;-)

	As distributed only the GENERIC kernel is guaranteed to configure 
	and build without errors.

	What to do when the linker complains about the size of a kernel
	is not covered in the documentation - sorry 'bout that, perhaps I'll
	take the mini-tutorial below and add it to the setup documentation
	some day.

	As a bit of background here is what goes on when a kernel is
	configured:

		cd /sys/conf
		cp GENERIC PICKLE
		vi PICKLE
		  ... turn on/off desired featuers,drivers,etc ...
		./config PICKLE

		At this point the 'config' script creates the directory
		/sys/PICKLE and populates it with various .h files describing
		what devices are present and so on.  Also copied into
		/sys/PICKLE are the various _prototype_ Makefiles: Makefile,
		Make.pdp, Make.pdpuba, etc.  Of these makefiles you are 
		only concerned with "Makefile" - the others should almost
		_never_ be edited.

		cd ../PICKLE
		make

		ld: too big for type 431

	First - what does that message mean?  '431' is the magic number for
	a split I/D overlaid executable.  Kernels are *always* split I/D
	and overlaid.

	The 'too big' part of the message means that the base segment and/or
	one of the overlays is larger than allowed.  What are the limits
	on the sizes (I hear you ask)?

	Kernels are a special case of overlaid program (user mode programs
	may be overlaid too but have less restrictive size rules).  The
	BASE segment (non-overlaid portion)  may be up to 56kb (57344) bytes
	in size.  In the case of the kernel the base segment must be a
	minimum of 48kb (this is not hard to do).  User mode overlays do
	not have the minimum size restriction.  Each of the 15 (maximum) 
	overlays (OV1 thru OV15) may be up to 8kb (8192) bytes.

	When 'ld' gives you a "too big" message the first thing you should
	do is:

		size unix.o

	That will produce something similar to:

	text    data    bss     dec     hex
	58304   7778    41206   107288  1a318   total text: 119360
        	overlays: 8192,6976,7680,7616,8000,7872,7680,7040

	As we see the base segment is over 57344.  To reduce the base we
	must move one of the files from the BASE group to one of the OV groups.
	Which one?  It is not critical but a the general rule is:

		The smallest one which will solve the problem.

	It is perfectly ok to put device drivers in overlays - especially
	disk drivers which tend to move large chunks of data per interrupt
	or call.  It is desireable to keep terminal drivers in the base but
	nothing bad will happen if you need to put one (such as dh.o) into
	an overlay.

	Next, look in the Makefile at the line starting with "BASE=" and do:
	a "size " command on all the files listed in the BASE section.

	How much do we need to reduce the base?  58304 - 57344 = 960.  So, 
	we need to find a .o (or more than one - it's the total of sizes
	that counts) in the BASE that is >= 960 bytes of text.

	In my kernel the overlay description looks like this:

BASE=   br.o cons.o dh.o dhu.o dhv.o dr.o dz.o hk.o ht.o init_sysent.o \
        kern_clock.o kern_descrip.o kern_mman.o kern_proc.o kern_prot.o \
	kern_subr.o kern_synch.o machdep.o ram.o kern_fork.o \
	rk.o ra.o rx.o si.o subr_rmap.o sys_inode.o sys_kern.o \
	tm.o tty.o tty_conf.o tty_subr.o tty_tb.o ufs_alloc.o \
	ufs_bio.o ufs_dsort.o ufs_fio.o ufs_inode.o ufs_namei.o \
	vm_sched.o vm_text.o xp.o quota_subr.o
OV1=    sys_generic.o ufs_syscalls.o
OV2=    kern_acct.o kern_exec.o kern_exit.o kern_resource.o
OV3=    kern_time.o sys_process.o ufs_mount.o ufs_subr.o \
	uipc_syscalls.o
OV4=    dkbad.o kern_sig.o mem.o subr_xxx.o trap.o tty_pty.o tty_tty.o
OV5=    quota_kern.o quota_ufs.o quota_sys.o ufs_bmap.o \
	sys_pipe.o
# OV6 gets the (hopefully) never used routines
OV6=    clock.o dn.o init_main.o kern_pdp.o machdep2.o subr_prf.o syscalls.o \
	subr_log.o toy.o vm_swap.o
OV7=    tmscp.o lp.o vm_swp.o rl.o mch_fpsim.o ts.o
OV8=    kern_sysctl.o ingreslock.o ufs_disksubr.o kern_xxx.o vm_proc.o

	We see that

		size kern_subr.o ufs_dsort.o

	gives

		text	data	bss
		820	34	0
		272	0	0

	820 + 272 = 1092

	58304 - 1092 = 57212

	which is great!  It's below 57344.  So, we've found the .o files which
	when moved to an overlay will generate a valid kernel.  Where should
	we put it?

	Well - OV2 looks a little small, is there room there?  8192-6976=1216.
	Yes, there is room.

	So, the kern_subr.o and ufs_dsort.o files are removed from the BASE
	section and added to OV2:

BASE=   br.o cons.o dh.o dhu.o dhv.o dr.o dz.o hk.o ht.o init_sysent.o \
        kern_clock.o kern_descrip.o kern_mman.o kern_proc.o kern_prot.o \
	kern_synch.o machdep.o ram.o kern_fork.o \
	rk.o ra.o rx.o si.o subr_rmap.o sys_inode.o sys_kern.o \
	tm.o tty.o tty_conf.o tty_subr.o tty_tb.o ufs_alloc.o \
	ufs_bio.o ufs_fio.o ufs_inode.o ufs_namei.o \
	vm_sched.o vm_text.o xp.o quota_subr.o
OV2=    kern_acct.o kern_exec.o kern_exit.o kern_resource.o kern_subr.o \
	ufs_dsort.o

	Then exit the editor and type "make".  And voila - no error and
	doing "size unix" yields:

text    data    bss     dec     hex
57280   7778    41206   106264  19f18   total text: 119424
        overlays: 8192,8064,7680,7616,8000,7872,7680,7040

	Perfect!

	*NEVER* simply delete files from the Makefile!  If you did not select
	a device in the config file - the .o is 0 bytes in size.  If for
	example you do not have an RK05 configured do a "size rk.o" and
	you will see that it is "0 0 0".  The .o is only 16 bytes long.

	That is why you won't notice any difference when moving/deleting
	some files - they don't have anything in them.  

	REMEMBER: "size" is your friend when adjusting overlays - get to 
	know and trust him.

	NOTE: There are some .o files which *must not* be moved out of the
	base segment.  These are identified as such in the Makefile.

	NOTE: You can not have any gaps in the overlays.  This means that
	there can not be a 0 length (empty) overlay between two populated
	overlays.  The last overlay used may be empty.

	IF all the overlays are full - then add OV7, OV8, OV9, etc lines
	(up to OV15) as needed and put .o files in them.  The Makefile will
	use the new OV lines automatically.

	I hope this makes things a little bit clearer for anyone building
	a 2.11BSD kernel.