[Aboriginal] Status update (sparc32).

[Rob Landley]

So the thing that's been holding up a release with the 3.1 kernel is
32-bit sparc support, which is _almost_ working (as in almost building
Linux From Scratch).  The uClibc fix that gets sparc dynamic linking
working is this:

--- uClibc-0.9.32.bak/ldso/include/dl-hash.h
+++ uClibc-0.9.32/ldso/include/dl-hash.h
@@ -111,7 +111,7 @@
   ElfW(Addr) relro_addr;
   size_t relro_size;

-  dev_t st_dev;      /* device */
+  int st_dev;      /* device */
   ino_t st_ino;      /* inode */

 #ifdef __powerpc__

Note that this has been broken in upstream uClibc for something like
FIVE YEARS.  Yeah that's a change to device independent code, and
probably not the _right_ fix, but at this point I'm willing to slap an
#ifdef on there and move on.

If I was shipping a 3.1 kernel, life would be good.  But 3.2 dies with a
symbol relocation error.  The kernel has a symbol relocator?  32 bit
sparc does!  And it breaks.

The problem is that a symbol winds up in the list that doesn't need to
be relocated, so the relocator doesn't know _how_ to relocate it, and
barfs.  It seems to be an off by one error, the symbol _after_ that one
needs to be relocated.  Where does the list of symbols to relocate come
from?  There's a tool arch/sparc/boot/btfixupprep.c which the Makefile
uses like so:

      cmd_btfix = $(OBJDUMP) -x vmlinux | $(obj)/btfixupprep > $@

It's parsing the output of objdump, and apparently doing it wrong.

The _other_ other problem is that when you get past _that_ (such as by
disabling the ext4 code containing the symbol the fixup code is barfing
on), you hit the kernel command line limit.  Openbios or something barfs
if qemu's -append option provides too much data.  So run-emulator.sh
boots but dev-environment.sh doesn't, due to the kernel command line length.

Whee...

Rob