> > I had this idea too, but unfortunately objcopy doesn't seem to work on
> > relocatable objects, only on fully-linked objects:
> ...
> > BFD: uvm_anon.o.elf: unsupported relocation type HI22
> > objcopy: uvm_anon.o.elf: Bad value
> 
> This smells fishy; I support GDB for vxWorks at Wind River, and I use
> objcopy on relocatable objects all the time. Probably something in the
> NetBSD support.
> 
> >   3 .bss          0003fb40  f01a7a00  f01a7a00  00193a70  2**8
> ...
> > I don't know why the .bss section would need to be 256-byte-aligned,
> > that seems kinda wrong to me.  I don't know what to make of all this, tho.
> 
> Apparently it is what our ELF toolchain wants to do for any file containing
> a 'static' array. Tested on a sparcbook running 19991223-current:
> 
> 	echo 'static char a[48];' > wide.c
> 	cc -c wide.c
> 	objdump -h wide.o
> 
> In my TADPOLE3GX kernel, the following objects have 2**8 .bss sections:
> 
> autoconf.o
> if_arp.o
> if_ethersubr.o
> in.o
> ip_proxy.o
> machdep.o
> promlib.o
> scsipi_verbose.o
> zlib.o
> 
> I wonder if perhaps somebody wanted these arrays to have an alignment of "8"
> but didn't realize that the sparc .common directive takes _logarithmic_
> alignment values instead of linear ones. The contents of wide.s include:
> 
> 	.common	a,48,8

My experience is that certain variables in the kernel use the
__align() directive.  This causes the compiler to do strange things.
Try removing all instances of __align() from the sources and recompile
those object files to see if the alignment changed.  This bit me before.

=========================================================================
Eduardo Horvath				eeh@netbsd.org
	"I need to find a pithy new quote." -- me