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