I have no idea what gcc is doing.

[Rob Landley]

I know x86 is a register-starved architecture, but gcc is just being weird 
about it.  Try this on for size.  In svn 15026 or so, do the following:

make distclean
make defconfig
make
mv busybox_unstripped busybox_old
make menuconfig
   Switch buffer allocation policy to "on stack".
make
make bloatcheck

Only a few things get rebuilt (we're not really using the buffer allocation 
macros much yet), but mdev is one that is, and that's the first two symbols 
here:

add/remove: 0/0 grow/shrink: 3/0 up/down: 201/0 (201)
function                                     old     new   delta
make_device                                 1127    1304    +177
mdev_main                                    328     348     +20
vi_main                                      318     322      +4

Why on _earth_ does make_device grow 177 bytes when temp is allocated on the 
stack instead of through malloc?  The reason we've got the macro in there in 
the first place is allocating on the stack is supposed to be _smaller_ than 
explicit calls to malloc.

To see what's causing the difference, run these in two separate windows (I 
haven't got them diff-friendly yet, which is not as easy as it sounds since a 
single inserted function will screw up all lines after that even if I 
renumber to start the counting at 0):

scripts/showasm busybox_old make_device | less 
scripts/showasm busybox_unstripped make_device | less

Interpreting the data and seeing the data are two different things, of course.  
Presumably the on-stack version is smaller on arm and such.  And maybe it was 
smaller with gcc 3.2.

I'm confused.  I'm trying to clean mdev up to be friendly to systems with no 
mmu, but I managed to remove code and wind up with a bigger result because of 
this, and that's frustrating...

Rob
-- 
Never bet against the cheap plastic solution.