Subject: Re: And just how big can it be? (Sun3/50 kernels..)
To: None <port-sun3@NetBSD.ORG>
From: Greg A. Woods <woods@most.weird.com>
List: port-sun3
Date: 11/23/1997 15:42:57
[ On Sun, November 23, 1997 at 19:10:34 (GMT), Greg Oster wrote: ]
> Subject: And just how big can it be? (Sun3/50 kernels..)
>
> Ok, so the kernel was 970K or so, which didn't seem to be *too* big, but ok, I 
> could trim a bit.... So I built a kernel that was only 770K... Same error... 
> "kernel too large for Sun3/50"...  I tried stripping the kernel -- 690K now... 

Remember that stripping an object doesn't make its load image any
smaller.

The only true way to see how big something will be when loaded is to use
the 'size' command:

15:35 [1] $ size /netb*
text    data    bss     dec     hex
814380  37504   76976   928860  e2c5c   /netbsd
846836  39072   82256   968164  ec5e4   /netbsd-1.3A971112-GENERIC
846876  39072   82256   968204  ec60c   /netbsd-1.3A971115-GENERIC
846876  39072   82256   968204  ec60c   /netbsd-1.3A971116-GENERIC
814380  37504   76976   928860  e2c5c   /netbsd-1.3A971117-WEIGHT
847016  39068   82456   968540  ec75c   /netbsd-1.3A971119-GENERIC
815456  38688   92636   946780  e725c   /netbsd-1.3A971119-MOUSETRAP-1

(netbsd is linked to netbsd-1.3A971117-WEIGHT)

The size in bytes of the file is either a poor indication, or possibly
even totally misleading (I can make a smaller binary that takes up more
room in core).  Never ever trust it in any case.  Don't even think of
doing 'ls -l' if your intent is to see how "big" the program is and you
cannot be given the wrong impression.

What I can't figure out is why the very few lines of change in pmap-88.c
caused do much difference in the text size:

text    data    bss     dec     hex
846876  39072   82256   968204  ec60c   /netbsd-1.3A971116-GENERIC
847016  39068   82456   968540  ec75c   /netbsd-1.3A971119-GENERIC

Perhaps there were other changes elsewhere that I didn't notice.
Actually that seems to make sense given the increase in bss too, as the
pmap changes alone definitely couldn't have caused this.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>