[Toybox] big endian problems

[Owen Shepherd]

> Rob Landley <mailto:rob at landley.net>
> 22 October 2014 17:42
> 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.
>
>> 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?
>
>> 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?
>
> 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.
>
> 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.
>
> 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
I don't have any info on MIPS ABI transitions, but I do have a few 
comments and corrections to make to that page (mostly regarding ARM, but 
a few other historical trivia):

  * ARMv5 didn't make Thumb mandatory (hence ARMv5T); that was ARMv6
  * Thumb-2 was actually an ARMv6 extension (ARMv6T2)
  * ARMv7-M also have a completely different exception model (ARMv6-M is
    a further stripped down version of ARMv7-M, not actually a
    predecessor). The M stands for microcontroller (much like the v7-R
    variant stands for Realtime, of the hard realtime sort). Being a
    microcontroller arch, backwards compatibility is pretty unimportant.
  * Big vs Little endian is a runtime distinction as well (APSR contains
    two bits - BE8 and BE32 - which can be used to switch into one of
    the two big endian modes, depending upon which your processor
    supports. BE8 is the one all modern processors support, BE32 is the
    one all older processors support, IIRC). Nobody that I know of would
    use "armv4tl" as an architecture designator
  * The ABI commonly called "OABI" is actually an old, deprecated
    version of the EABI (it was deprecated because it didnt' interwork
    with Thumb code, or indeed work with Thumb very well at all). Linux
    took the opportunity to rework its' system call ABI at the same
    time. You can run EABI software on ARMv4 (no Thumb), with some
    caveats (you need to translate all BX instructions into MOV PC
    instructions)
  * Motorola didn't get their engineers back in their lawsuit against
    MOS Technologies. The eventual settlement was that MOS would
    discontinue the 6501, a 6800 pin-compatible variant of the 6502
  * Following on from this, the 68000 was the successor to (and designed
    by the same team as) the 6809, Motorola's "6800 v2", done after the
    engineers left to found MOS (several of which would later move to
    the Western Design Center, which produced the 65816. WDC are an
    interesting example of did something two decades ago, still living
    entirely on the results of that thing)
  * The Acorn BBC Micro was a 6502 based machine. ARM was developed for
    its' 32-bit successor.
  * AArch64 is a completely revised architecture. In particular, it has
    a new, cleaner instruction set; the system register set has been
    redesigned; the whole privilege level and hypervisor functionality
    has been redone; the general purpose register file has been enlarged
    and all special purpose registers removed (SP is no longer in the
    register file, for one). I wouldn't be so sure of a merge.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20141023/bf7d0a07/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20141023/bf7d0a07/attachment-0002.jpg>