Open chrysn opened 1 year ago
LTO should be the default anyway, as this yields significant gains; being able to run more apps without soldering in a new MCU with more RAM/ROM is something we should do, regardless of this discussions.
With that, we don't gain anything from static inline
anymore. If we would move then all static inline
to C files, we could avoid including vendor header files in our headers. The vendor header files are perfectly fine C headers, but typically are not C++ conform (even in extern "C"
). g++
is quite tolerant to C-but-not-C++ conformant code, while clang++
is not. This is why we stopped compile-testing with LLVM. Move static inline
stuff to C file would be a major step towards regaining LLVM support (likely other issues have sneaked in in the meantime that would need fixing as well).
Getting our linker scripts compatible with other linkers is something that IMO would be worth some effort. I think that XFA may have raised the bar a bit here, though :/
I don't see any trouble with XFA: It's just another section that gets linked into RAM or ROM, that should be a regular feature. The trouble IIRC was that we did some constant arithmetic to be able to do things like accommodating different chips in a series with different sizes of memory in different situations of using or not using a boot loader and other flash size shenanigans -- where the alternative is to either have combinatorial lot of such files, or to generate them with a very small shellPython script.
I can confirm that with fixed ldscripts, cross-language-lto works between Rust and RIOT's C code. The arithmetics in ldscripts is indeed the problem. I worked around that by hard-coding the arithmetic results, which only makes sense for a single board and for testing. I'd love if we could fix this!
Description
C2Rust is an extra that occasionally causes trouble, eg. in https://github.com/RIOT-OS/RIOT/pull/19495#issuecomment-1519972727, where I was tempted to answer:
… so instead, I'm opening this.
I'm not sure now is a good point in time, neither ever, but let's at least use this issue to hypothesize, and to collect material, show-stoppers and input.
Why we use C2Rust now
static inline
functions usable from a linked program. I'm marking this as "solved" because bindgen has learned to turn public static functions into non-static functions that can be linked when an extra generated C file containing all their implementations is linked -- so there is a viable solution, but see next point.If we could tick all these boxes, we could migrate off C2Rust. But that'd probably only fly if there were other reasons as well that'd justify ticking the boxes. Do we have them?