I work for the company that makes the device targeted by this linker script (I work on the compiler toolchain) and I am very familiar with GNU ld linker scripts. I consider its language to be the worst I’ve ever used. I am not being hyperbolic. If you can go without having to touch them, then I recommend you do so.
This is a nice primer for understanding the basics of linker scripts. One thing that was a bit underemphasized is the tight integration with the startup and library code. You need KEEP around all those input section descriptors because the linker will remove them if they are not referenced and you use --gc-sections, which is typical when building for embedded devices. Most of those symbols are “magic”. (Also note: they all start with an underscore because they take advantage of the rule in C that says external identifiers that start with an underscore are reserved.)
Things get really with hairy with GNU linker scripts when you have to start placing things at specific memory locations. This is common on such devices. This linker script is very simple. There is no oddball memory configuration with heavily customized placement of code and/or data. The GNU linker script language is really, really bad for doing these things.
I am surprised there is so much concern about heap space. A SAM D21 only has, at most, 32KB of SRAM. Apps on such small devices general don’t (and shouldn’t) use malloc. You open yourself up to many problems this way. It is better to restructure your app so that all memory space, aside from stack space, is known at build time.
I am very familiar with GNU ld linker scripts. I consider its language to be the worst I’ve ever used.
Are there any good alternatives? There were some discussions on the lld mailing lists about adding something different but no non-GNU linkers seemed to have something that was sufficiently powerful for the things that people use linker scripts for and / or as readable as the incredibly low bar set by GNU ld. I’d love to see a better replacement.
I haven’t used the linker from IAR, but I have seen their linker control files and they are much simpler to read. I can’t speak to their expressiveness. SEGGER has a new linker and its syntax looks a lot better; I haven’t had time to really look into it. Both of these are geared toward embedded systems, of course. As for large projects, I simply don’t know what might be missing.
I don’t know that there is a good alternative to GNU ld linker scripts, which is disappointing, really. I suspect it’s because writing a linker is a lot of work so you just use what’s there. If lld is looking at something else, maybe I should see what I can do to help out. I would love to be able to provide something more approachable than the mess that is GNU’s syntax.
Very nice exposition of a pretty obscure aspect of software development. I also found “Linkers and Loaders” by John Levine useful when diving into this topic back in the day.
I work for the company that makes the device targeted by this linker script (I work on the compiler toolchain) and I am very familiar with GNU ld linker scripts. I consider its language to be the worst I’ve ever used. I am not being hyperbolic. If you can go without having to touch them, then I recommend you do so.
This is a nice primer for understanding the basics of linker scripts. One thing that was a bit underemphasized is the tight integration with the startup and library code. You need
KEEParound all those input section descriptors because the linker will remove them if they are not referenced and you use--gc-sections, which is typical when building for embedded devices. Most of those symbols are “magic”. (Also note: they all start with an underscore because they take advantage of the rule in C that says external identifiers that start with an underscore are reserved.)Things get really with hairy with GNU linker scripts when you have to start placing things at specific memory locations. This is common on such devices. This linker script is very simple. There is no oddball memory configuration with heavily customized placement of code and/or data. The GNU linker script language is really, really bad for doing these things.
I am surprised there is so much concern about heap space. A SAM D21 only has, at most, 32KB of SRAM. Apps on such small devices general don’t (and shouldn’t) use malloc. You open yourself up to many problems this way. It is better to restructure your app so that all memory space, aside from stack space, is known at build time.
Are there any good alternatives? There were some discussions on the lld mailing lists about adding something different but no non-GNU linkers seemed to have something that was sufficiently powerful for the things that people use linker scripts for and / or as readable as the incredibly low bar set by GNU ld. I’d love to see a better replacement.
I haven’t used the linker from IAR, but I have seen their linker control files and they are much simpler to read. I can’t speak to their expressiveness. SEGGER has a new linker and its syntax looks a lot better; I haven’t had time to really look into it. Both of these are geared toward embedded systems, of course. As for large projects, I simply don’t know what might be missing.
I don’t know that there is a good alternative to GNU ld linker scripts, which is disappointing, really. I suspect it’s because writing a linker is a lot of work so you just use what’s there. If lld is looking at something else, maybe I should see what I can do to help out. I would love to be able to provide something more approachable than the mess that is GNU’s syntax.
This is the same as: https://lobste.rs/s/wbe23w/thoroughly_commented_gcc_linker_script
Ah, you are correct! I must have missed that in the new stories.
IMO this link is better than the one I posted, since this is a full write-up of the script.
Very nice exposition of a pretty obscure aspect of software development. I also found “Linkers and Loaders” by John Levine useful when diving into this topic back in the day.