> 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

Todd Whitesel
toddpw @ best.com