On Mon, Nov 27, 2023 at 4:05 PM enh <[email protected]> wrote: > > On Mon, Nov 27, 2023 at 3:32 PM Rob Landley <[email protected]> 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"... _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
