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

[enh]

On Mon, Nov 27, 2023 at 4:05 PM enh <enh at google.com> 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].)

(but if you think _that's_ going to let me delete 32-bit code, well,
there's nothing that says you can't ship an SoC with armv9 big cores
that only run 64-bit code and armv8 little cores that run both, or
vice versa. which is the worst of all worlds from _my_ perspective,
but obviously commercially useful for folks who want to still be able
to run old 32-bit binaries on new hardware without dynamic binary
translation.)

> 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.
>
> > I had to add a second override, and then
> > teach the build to lie extra with a non-matching --host in order to get 32 bit
> > hosted arm toolchains built for the next release.
> >
> > All the personality(PER_LINUX32) syscall _does_ is get uname and /proc to
> > lie-to-autoconf about the architecture! It doesn't stop you from launching new
> > 64 bit executables, or change memory mappings or CPU flags or anything. It just
> > makes the queries return different info... and they got it wrong.
> >
> > Sigh. I removed my horrible #ifdef stack from uname because I thought linux32
> > covered it, but I hadn't tested other host architectures...

going back to strace, if i haven't said already, this is why i'm
slowly starting to poke at toybox strace --- because there's a ton of
complexity in dealing with multiple personalities (especially as one
execs the other and back again!) that ... if i just drag my feet a
little bit, will probably only be of historical interest by the time
we're ready to think about going from "default n" to "default y" :-)

afaict the linux distros are slowly heading towards x86 deprecation/removal too.

> > Rob
>
> ___
> 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"...