BUG? x86_64 code on RasPi 4/arm64

[rcfa]

I followed the instructions here: https://www.kali.org/docs/arm/x86-on-arm/ but whenever I try to run some amd64 linux binary I get "uncaught target signal 5" and similar errors, or "Exec format error", but no successfully running app...

4916

What am I doing wrong here?

[Fred Sheehan]

It does say how to run x86 code, i.e. 32 bit code NOT x86_64 code i.e. 64 bit, i.e. its an emulated x86 CPU so AMD64 code will always fail..

[rcfa]

Oh! OK 🤦🏻*♂️

Seriously, though, who?s still running 32-bit code on x86? Especially on a recent release OS?

The only reason I need this, is for some commercial software not released for arm64 (essentially cloud services) and it?s all x86_64.

Any chance something like that can be done for amd64/x86_64? That would be a lot more useful?

[Fred Sheehan]

Because x86 MEANS a 32 bit CPU i.e. it cannot process more than 32 bits at a time..

x86_64 MEANS a 64 bit CPU that is backwards compatible with x86 (32 bit) programs, i.e. it will run 64 bit OR 32 bit programmes

(technically speaking modern CPU's don't actually use the full 64 bits but only 48 bits for the instruction set and memory addressing, but were getting way out of scope here..) :)

If you need emulation for different platforms your in the world of virtual machines, try virtual box

[rcfa]

I?m fully aware of what you write, it was simply so far out of the range of the expected, that this day and age anyone, on a modern platform, would want to care running ancient 32-bit code, when the real need is to run modern code, almost all exclusively 64-bit code, which isn?t available on arm64, because boneheaded commercial software providers are still stuck in an intel-only world from a decade ago.
So, yes, my mistake for not reading precisely enough?
To be clear: had this been a retro gaming platform, or a legacy systems emulation tool, I would have read x86 to mean 32-bit; but in to context of running another CPU family?s code on a 64-bit modern platform, the false default assumption was that ?x86? was used generically to contrast ?arm?, not specifically to contrast ?x86_64?, given that it?s probably a decade or more since intel introduced a non x86_64 x86-compatible CPU.

[Fred Sheehan]

There are lots of architectural differences that make it impractical to do so, like x86_64 code being big endian and CISC instruction sets, whereas ARM64 is little endian and RISC architecture, i.e Complex OR Reduced Instruction Set Computing, architectures respectively. The 'endianess' is relatively easy to fix, the far reduced instruction set on the other hand much more so)

The only people I know of who do actualy offer x86_64 emulation on any ARM based platform are Microsoft with their Windows ARM edition OS, but thats it.

[rcfa]

All x86 and x86_64 is little-endian. m68k and possibly PPC are big-endian.

Besides M$, there?s Apple?s Rosetta, QEMU, and of particular interest in this context, Box64!
They all do just fine despite the CISC-RISC thing.
Heck, many CISC implementations internally use microcode, which isn?t all that different from RISC instructions.

https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/

After reading the above benchmarks, I wonder if it wouldn?t be useful to have box86/box64 packages as part or arm64 Kali; as unfortunately there?s still too much software that?s not arm64 native.

https://github.com/ryanfortner/box64-debs
https://github.com/ryanfortner/box86-debs