[Toybox] big endian problems

Fri Oct 24 14:27:46 PDT 2014

On 10/22/14 11:21, Rob Landley wrote:
> On 10/22/14 09:25, James McMechan wrote:
>> I was trying to do a multi-architecture buildall and it blew up on the
>> 2nd architecture on both sparc and ppc it seems the toybox md5sum
>> sha1sum are not big endian safe, i have not puzzled out the logic yet.
>
> Sigh. It _was_ bigendian safe, before I applied the unroll patch to
> speed it up back in may.
>
> I have a second unroll patch applied to my local tree that speeds it up
> further, but it's just too ugly for words. I've been meaning to poke at
> this and try to clean up the faster version, but getting it to be both
> simple and fast is _hard_, and haven't made a big enough block of time
> to sit down and stare at it yet.
>
> I hadn't done a proper retest because I wasn't done changing it. My bad,
> sorry. I'll build a fresh powerpc test image here and at least fix the
> big endian failure today.
>
No hurry from my side, I just stuck a working version in host-tools for
PPC and SPARC.  I was just trying to isolate the problem, so it did not get lost.

>> Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works
>> required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so native
>> compiler would build under arch linux
>
> Um, did you make this change _to_ arch linux? (Confused, the aboriginal
> linux system image I have lying around already has /dev/null chmod 666,
> and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to
> libc.so.0 is... ouch?
>
yep, I made the changes to arch linux's /dev/null and /lib/libc.so.0 -> /lib/libc-2.18.so
for some reason host tools wanted that in order to build native compiler
I was building armv5l first so maybe it got confused, I removed the symlink and built
i686 on arm to see if it reoccurred but i686 built fine without the symlink (303m).
building armv5l without the symlink blows up again for example:

<snip>
config.status: executing default-1 commands
config.status: executing default commands
make: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory
sh ../libtool --tag CXX --tag disable-shared --mode=compile armv5l-c++  -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/build-gcc/armv5l-unknown-linux-gnueabi/libstdc++-v3/include/armv5l-unknown-linux-gnueabi -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/build-gcc/armv5l-unknown-linux-gnueabi/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++  -fno-implicit-templates -prefer-pic -Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections -fdata-sections  -g -O2  -D_GNU_SOURCE  -c -o del_op.lo /home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++/del_op.cc
<snip>
/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++/del_op.cc:45: error: expected constructor, destructor, or type conversion before 'void'
Makefile:519: recipe for target 'del_op.lo' failed
make: *** [del_op.lo] Error 1

Exiting due to errors (armv5l native-compiler gcc-g++)

real    85m41.170s
user    70m46.050s
sys     5m38.270s

real    228m58.799s
user    193m1.060s
sys     15m3.910s

kind of painful 3h 48m into the compile and 4h 47m for the successful compile
most of my faster ARM systems are doing other stuff e.g. phones/tablets
but a NAS is powered on for days normally so it can spend lots of time compiling.

>> took 287m for a single arch compile
>>
>>
>> my other systems are still in need of work
>> AMD Athlon64 - power supply replacement
>> Intel P75 24MB - networking problems
>> hp sh3 32MB - have not yet got aboriginal to build for sh3
>
> Oh wow, you have an sh3 test system?
>
The HP 660LX Palmtop PC is actually a quite nice little computer
currently I can run jlime.org linux on it but that is quite old at 2.6.17
It has a 640x240 touch screen with stylus and full keyboard and
PCMCIA (but Yenta chipset non-cardbus cards only), and a compact flash slot
for mass storage, a 75MHz sh3 and 32MB.  More then my father's pentium 75
laptop expanded to 24MB the gcc-3.4.5/glibc-2.3.5 crosstools build environment for
jlime is of course the usual hairball.

> I'm currently trying to get aboriginal to build for sh2, which is nommu
> and thus weird. (I've got a little xylinx fpga here with an sh2
> bitstream, and an old code sourcery sh2 toolchain hooked into a
> buildroot fork with a kernel and such.) I've already got sh4 working in
> aboriginal, so collecting the whole set would be nice on general principles.
>
no-MMU is more old school and painful than weird ;) I got started on systems
before MMU's were so common on microprocessors, I built a lot of realtime systems
starting with both 68000 and 80186 boards using 128KiB RAM later we maxed
them out at 512KB per processor board, getting multiple both big and little endian
processors to use shared memory and locks at the same time was interesting...
Ah for the days of yester-year when you could spend a pile of money and have a
multi-user system without a MMU we did eventually upgrade to a development
system with a 68020 and MMU and later upgraded from SCCS to CVS which is much
much nicer. That also got rid of the 8" floppies and 8" hard disks at a generous 40MB

> Adding sh2 and sh3 support to qemu is also on the todo list. I _think_
> it's mostly a question of chopping sh4 down to the earlier/smaller
> instruction sets (and disabling the mmu for sh2), but I have a giant PDF
> to read through to see what the actual differences are...
>
>> TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel
>> hoo-too Tripmate Elite - also MIPS not yet tested
>
> mips has a sort of oabi/eabi thing going on, where the old mipsr4k
> binaries I'm building (with the hard 256 meg memory constraint) are
> being replaced by "mips32" which is some confusing thing I need to read
> up on and has some kind of "kernel space code and userspace code aren't
> the same thing" weirdness going on that I got half an explanation of and
> don't understand.
>
I have just brushed up a bit on MIPS again I used to work with them a little
I think it was a crimson honking big rack with lots of fans and big twist-lock
220V 30A power connectors for the racks which alas did not have the colored
panel just big SGI brown doors, the personal Indigo we later used as a system console did
have the coloured case in sort of blue purple. Hunh, looks like what we had was
a SGI SkyWriter 4D/510 (crimson) R3000 system which could also have upto 256MB if you
maxed out the memory boards in the rack with 4M SIMMs and the first console was
likely a 4D/35 Personal IRIS also R3000.
Even the Indigo when it switched to blackjack with standard 72pin SIMM could
do 384MB and that was about 1991-3 and it was full 64 bit using R4000 MIPS-III the
32bit R3000s from the very first Indigos was from 1988 and used MIPS-I and could only do
96MB with SGI memory modules.
According to some of the notes for more than 384MB you need to boot a 64bit kernel
MIPS32 looks like MIPS-II + bits from MIPS-III, MIPS-IV & MIPS-V but without the 64bit
mode MIPS-III (R4000) and later instruction sets all had.
The Indy low cost pizzabox used FPM SIMMs but could only go up to 8x32MB for 256MB
Pretty much all others of the ones using standard FPM SIMMs could take more memory
even back in the 1990s where is this hard 256MB limit from?

> If anybody has a decent explanation of that lying around, I'd love to
> add it to the link collection. I never properly finished:
>
>   http://landley.net/aboriginal/architectures.html
>
> Because I don't _know_ this information, and what research I did do is a
> bit stale now...
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net

 1414186066.0