The asm version won't allocate memory either. But for the originally stated objective of nailing a variable to a particular location it does the same job and maybe gives a tidier syntax.The pointer will not allocate memory and can be deadly if overlaps with something else.
For the higher level purpose of exchanging data between separately compiled executables, the problem with all of these approaches is that they don't allocate memory and hence require manual maintenance of the addresses. Linker sets do allocate memory to multiple variables, but if there's more than one variable then it doesn't guarantee the ordering in the separate builds, so that doesn't really help.
My inclination would be to define a structure and anchor it either with the const pointer approach (I don't think I mind the extra typing of shared_vars->var1 instead of just var1, as I'd like a strong indication in the code using it that there's magic involved), or by anchoring that struct by putting it in a linker set and forcing the address via the linker script - much more work, but does guarantee that the linker doesn't put anything else there. However, compared to Hippy's approach I'm just trading risk of making manual arithmetic errors in assigning the addresses against risk of different compilers doing the structure packing differently.
It feels like 'doing it properly' would involve compiling a single .elf file containing all the variables to go in both builds - probably needing some kludge to change the binary type of the .o file so the linker will accept it, and still requiring a custom linker script to anchor it in the chosen place. But it's kludgy and I'm not sure it's actually better.
Statistics: Posted by arg001 — Sat Mar 22, 2025 5:47 pm