Compiling Out of Tree Driver with Different Version of Toolchain Than was Used to Compile Kernel


General question.

Is it valid to cross compile an out of tree driver with a different version of the cross compiler/toolchain than the kernel was compiled with? If not, where do you draw the line?

Recently we re-compiled an out of tree WiFi driver for the BBB on a PC host machine, pointing it at the kernel source tree with all of the build products/generated files in it. The kernel was built with the 6.4.x Linaro toolchain, however the developer built the WiFi driver with the Linaro 5.4 toolchain. The developer was able to deploy the WiFi driver to the target, and it worked just fine.

I mentioned to the developer that, in general, it’s probably safer to use the same brand and version of the cross toolchain to build the driver and kernel, but now I’m so sure that this has to be the case. For instance, If the function call interface is standard for all versions of the Linaro toolchain, then maybe this doesn’t matter. However, if version 4.x uses one set of registers to pass function parameters to a driver, for instance, and the driver is compiled with a different version of the compiler which expects the parameters to be passed in a different set of registers, then there would be an issue.

What’s the rule of thumb here or what’s a good reference to better understand the interfaces?

What you mentioned (register use and parameter passing) is known as
calling conventions, which are part of the full ABI (Application
Binary Interface) which specifies those and other details of the
target platform:

As long as the ABI is compatible, you should be able to compile kernel
modules using whatever compiler you want.

There are lots of different ABIs for the ARM platform because there
are a wide range of CPUs with different features (eg: hard floating
point, NEON support, thumb instructions, etc). That's why you wind up
with long lists of cross-compiler tool chain variants, eg:

Thank you sir!

Good references.

Ok, the ABI is the standard interface at the machine code level, as opposed to API.

Yeah, you often see the name ABI/EABI with cross compilers for embedded systems. I’ve seen that enough times that I should have looked there. Will forward this post onto my colleague…