[Aboriginal] Status update (sparc32).
rob at landley.net
Wed Nov 30 04:22:33 PST 2011
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:
@@ -111,7 +111,7 @@
- dev_t st_dev; /* device */
+ int st_dev; /* device */
ino_t st_ino; /* inode */
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.
More information about the Aboriginal