Investigate templating system for linker scripts (C Preprocessor? Lua? Python?)
mysterymath opened this issue · comments
We now have a very large body of very formulaic code in our linker scripts, for want of abstraction features in the linker script language. We've also started writing lua/awk generators for some of them, but this is a fairly heavyweight mechanism. A simple, but fraught, way of getting abstraction is to hook up the C preprocessor; lld won't do it automatically, but we could run it in CMake as part of building the SDK.
This bears further experimentation to get a sense of the benefit/detriment to readability and the maintenance overhead to our CMake. We should only do this if we can resist the temptation to go macro-crazy; the increase in readability must be very substantial for this to be worth it. But, I do suspect it might be.
The main problem I've ran into with C macros is that they're not great at doing arithmetic; one could, of course, leave the arithmetic part to lld, but this would probably scale up to subtly impacting linking performance at the scale of hundreds of sections.
I'm going to lobby towards standardizing on Lua (which is an LLDB dependency regardless, alongside Python - though it may be optional...), but I will fully admit that I am unusually biased here as a long-time Lua enthusiast.
(I'm willing to do some work on cleaning up the scripts in case they were to become an actual part of the SDK compilation process and not just a leftover from my work committed for preservation's sake.)
The main problem I've ran into with C macros is that they're not great at doing arithmetic; one could, of course, leave the arithmetic part to
lld, but this would probably scale up to subtly impacting linking performance at the scale of hundreds of sections.I'm going to lobby towards standardizing on Lua (which is an LLDB dependency regardless, alongside Python - though it may be optional...), but I will fully admit that I am unusually biased here as a long-time Lua enthusiast.
This is a good point; it would also matter whether the arithmetic expressions we could generate from the preprocessor would be gibberish or readable and meaningful. I'd take that as an additional success criteria: the generated output may be much more verbose, but it should be as clear as the input linker script.
The main advantage to a macro language over a generator is the ability to mix abstractions into the unabstracted source text. The generated output is implicit in a generator; in a macro language, one can pretend that it's just a linker script, but with function definitions. I'd argue that our linker scripts are still mostly linker scripts, and that's the ideal level of abstraction to work at. That is, if you actually could define a function in LD to generate a section definition given some input arguments, doing math and so forth, it would be pretty clear that that's the way to go, but que sera.
I do doubt that we'll seriously stress LLD with our tiny embedded platform though; the bits of the linker script parser I've read are pretty efficient Dragon Book stuff, and our linker scripts are similar in size to those I've seen from other embedded projects in the wild (amazingly). It is the case that the smaller the project, the bigger the linker script, though; so this is one case where we can't do anything crazily n^2.
We could import a simple templating library if you want to use Lua like .PHP. macros, think pl.template or something even more self-contained.
Was thinking about that; the main advantage of the C preprocessor at that point is that it's familiar and doesn't add a new dependency (we can use the one in llvm-mos clang). That may very-well be outweighed by other concerns; particularly lack of a looping construct seems likely to be fatal now that I think more on it.
LISP! LISP ALL THE THINGS!