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

[enh]

On Tue, Nov 28, 2023 at 3:51 PM Rob Landley <rob at landley.net> wrote:
>
> 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?

yes, it was...

...but 32-bit wasn't _removed_ at that time. in fact, 32-bit was
_improved_ in armv8. (and given a shiny new "aarch32" name.)

armv9 is where they drop 32-bit. (but that's very new, and still
incomplete --- the X2 and A510 cores can no longer run 32-bit code,
but the A710s can. but i think qcom has an A510 variant that can still
run 32-bit code. so although _some_ armv9 SoCs will be 64-bit-only,
most armv9 SoCs atm can still run 32-bit code.)

it's certainly complicated enough that i'm not surprised you're
confused. this stuff is my day job, and i had to go and look up which
of the cores can still run 32-bit code, and i'm still not sure i got
those all correct.

> 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.

i'm not sure he deserves any credit for japan having more money than 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.

yeah, we see a similar 20-25% for 32-bit armv8. (and better for some
things: several of the libm functions are single instructions in
armv8, and there's the crc/AES type stuff i mentioned before.)

> (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...

they've abandoned the former, but armv9 is only a couple of years old,
and i have no reason to assume we won't see an armv10... and in the
meantime, we've been having armv8.5 etc, and are already on armv9.3
for values of "on" that include "there's a published spec". arm's
website is generally terrible and links don't last more than a month
or two, but if you click
https://developer.arm.com/documentation/102378/0201/Armv8-x-and-Armv9-x-extensions-and-features
right now you should at least get a decent summary of what was in
everything post armv8.0, which is Android's arm64 NDK ABI.

> Rob