[Toybox] [PATCH] strace: fix arm64 test.

[Rob Landley]

Typed on the plane back to Austin...

On 11/27/23 18:05, enh wrote:
> On Mon, Nov 27, 2023 at 3:32 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 11/27/23 17:16, enh via Toybox wrote:
>> > We're not specifically looking for armv8; we want any aarch64.
>> >
>> > I've also changed the 32-bit arm test because (a) Linux doesn't
>> > support arm32 OABI any more, (b) it's clearer this way that 32-bit
>> > armv8 still belongs in this branch, and (c) __arm__ and __aarch64__
>> > are the usual spellings everywhere. (Sure, the latter is ugly, but
>> > we have __i386__ rather than __x86__ one line later anyway! I still
>> > have to grep AOSP for mistaken uses of the non-existent __x86__ on
>> > a regular basis. And don't get me started on __riscv and __riscv_xlen!)
>>
>> Did you see my Nov 18th blog entry about "linux32" making my new pi-alike say
>> "armv8l" instead of "armv7l"?
>>
>> There was no non-64 bit armv8. Moving to 64 bit was what armv8 introduced. The
>> last 32 bit architecture was armv7.
> 
> i have a phone in my pocket that says you're wrong :-)
> 
> (this is what aarch32 is --- it's 32-bit armv8. there's no 32-bit armv*9*[1].)

I remember when armv8 came out, and I _thought_ the 64 bit stuff was introduced
at the same time? I suppose 32 bit armv8 could be like armv7r where they yanked
the mmu but did NOT also switch to thumb: technically possible but I still
haven't actually seen one and couldn't get qemu to do it last time I tried. I
first encountered that aarrcchh6644 branding exercise came along sometime later,
and always struck me as one of those ia32 vs x86 where marketing people at a
company are being slimy somehow, in a way I never bothered to track down. (Of
course gnu would fall for it.)

The superh patents ARM had been licensing to do the thumb stuff expired about
the time cortex-m exploded, because without having to pay those per-chip
licensing fees it was now the cheapest option for what it did, but I stopped
trying to closely track of who owned what arm fork when Intel bought strongarm
and completely faceplanted. I had to deal with scorpion when I worked at
qualcomm (they were our political rivals in Research Triangle Park, with Hexagon
happening out of Austin, and genericizing hexagon was done VERY QUIETLY so they
wouldn't find out and kill it by appealing to the real power in the company: the
legal department. Spoler alert...). And I followed softbank buying arm from the
brexit clowns looting the country, on the basis A) I was in Japan at the time,
B) at least Boris didn't sell it to Russia.

> funnily enough, i'm starting to have a problem with third-party open
> source projects that don't believe there was 32-bit arm before armv8
> (because they don't see armv7 any more), so they'll unconditionally
> use new 32-bit armv8 instructions and go boom on armv7.

i486, i586, i686... Sigh.

I remember that recompiling from armv4 to armv5 had a 25% performance
improvement. I believe armv6 was just SMP support and not performance, and then
armv7 was performance again? Somebody explained it to me once but no idea where
I wrote it down, and it predated armv8 coming out. (And half the FPU "neon"
factionalization.) Hmmm, I mentioned it in
http://landley.net/aboriginal/architectures.html#:~:text=provides%20about but no
clue where to look for more details. (I think it was the timesys guys? That
would have been 2006/2007. No idea where Walt Wermer and Lamont Yaroll and so on
have got to these days. I probably got an updated explanation from Dave Anders,
ala prpplague, but he disappeared into working for Intel years back and I
haven't heard from him since. David Mandala similarly wandered off... I miss
having an ambient smarter-than-me peer group who regularly explained stuff at me.)

People made i386 binaries for the longest time because "most portable". Alas the
i386 of arm was armv3, but OABI->EABI required thumb instructions in the syscall
interface so switching to it dropped support for everything before armv4t. (Rich
Felker explained that part to me at one point: you CAN do an armv4 EABI but most
build environments don't bother.)

That's why I build/test/ship armv5l and armv7l toolchains but not armv6l. Armv5
was the first one where the thumb instructions were mandatory, so while I
theoretically _could_ do an armv4t the gnu/crap always fought tooth and nail
when I tried, and then armv7l should have a decent performance boost (and some
kernel builds required it because of inline assembly).

> 1. not to be confused with the 32-bit-only arm9, of course. don't get
> me started on "when marketing gets involved in naming things"...

I remember. arm7 vs armv7, the v meaning "architecture" and the one without the
v meaning "SOC generation". These days they seem to have abandoned both...

Rob