[PD-dev] multi-architecture deken packages

[IOhannes m zmoelnig]

On 4/15/21 12:33 AM, Alexandre Torres Porres wrote:
> Ok, I got questions now on how loading works. We know .pd_linux for
> instance, can be used generically for any architecture. But I guess Pd
> knows if that .pd_linux file is actually good or not. Like, let's get the
> zexy bundle, for instance, you have 4 linux versions there and one is
> .pd_linux, how do the other 3 know that this .pd_linux. is not for them,
> right? Same thing would be true for other generic extensions such as .dll I
> assume.

Pd doesn't do any loading.
it defers this to the operating system.

the OS will open the file and perform some header checks, to know 
whether the contents of the file is actually a loadable library.
once it has established that it is, the library is loaded. and as soon 
as you run a library function, the machine code encoded in the binary is 
executed.
the important part here, is that the sanity checks are only done during 
the load process and it's only the meta-information (the header) that is 
inspected.
now the header typically lists the Operating System ABI (see [1], which 
includes the target architecture.
however, there are zillions of slightly different CPUs out there, so - 
like Pd and deken - this architecture field only gives the *CPU family*, 
rather than the specific processor.
if the CPU family of the binary is incompatible with the current 
runtime, then the library cannot be loaded.
this is why we can have a zexy.pd_linux that is really Linux/amd64 
without any problems, even if we are installing the library on a RPi: Pd 
will try to load the file, but the OS will tell it that it can't. so Pd 
will just try the next file and eventually and hopefully will come 
across a zexy-binary that matches the CPU family for the RPi.

if the CPU family of the binary does match the CPU family of the current 
runtime, then the library is loaded.
if during execution the CPU encounters an unknown instruction (e.g. an 
SSE4 instruction on an old i386 CPU), it will segfault with an "illegal 
instruction" error.

> But then, there may be an exception here only for armv6 x armv7, where
> it just can't really know, right?

as said above, it's actually the very same for other CPUs as well.
if you have Mac Mini, October 2014 (that comes with the Haswell variant 
of the intel CPU) and try to run a binary that was optimized for an 
intel Coffee Lake CPU (Mac Book Pro, July 2018), you are likely to 
experience illegal-instruction segfaults.

that's why binaries are usually built for a more generic "baseline CPU" 
(unless your specific usecase actually demands all the processing power 
you can ever get, in which case you either need to self-compile turning 
on heavy optimization for your target CPU; or hope that the vendor 
provides a separate binary specifically targetted at your CPU)

gfmasdr
IOhannes


[1] here's the description of the linux ELF format; on macOS and W32 
other formats are used, but the idea is the same:
https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#File_header

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210415/58999bb8/attachment.sig>