Is there a way to prevent cross references betweeen two sections, so that for example functions located in the .boot section can't call functions located in the .user section? I'm developing a custom bootloader and I need it for obvious reasons. I've digged through the scatter loading documentation but I didn't find the equivalent of the NOCROSSREFS() directive used in ld. (I'm using armcc and armlink)
The way to do it is to use two projects or two targets in the same project.
If you need to, you can later merge the hex for the boot loader and the application and send off to the factory.
Only separate builds will guarantee water-tight separation - or the use of assembler. You can never control what internal helper functions C/C++ code may use and any reference to CRTL functionality will be bad news.
The last thing you want is to keep updating a boot loader, keep it in another project, and don't allow it to be modified without a waiver. Code it correctly and effectively the first time around, imagine it's in ROM, and will cost more than your yearly salary to replace it. Doing so will also significantly reduce the chance of bricking your systems.
If you have a lot of common code, use a merge tool.
As Per indicates there are too many things the compiler/linker can do if you're not managing it all in assembler. Consider who has to maintain the code after you, and the impact of changing/updating compiler/tools in the future.
Per, Pier, thanks for your advice. We are switching from Microchip to ARM, and with Microchip we had developed a working bootloader source splitted in two parts: a bigger part, that after a "warm-up" period has remained unmodified for years, and a custom part, different for each project/microcontroller. This approached had proved to be fast and effective, and with no post-build overheads. The NOCROSSREFS() directive was enough to prevent calls between each section.
Anyway I see that even if I use the ld file instead of a scatter file, the NOCROSSREFS directive is not supported: infocenter.arm.com/.../BABCJGDD.html I think that this comes from a lacking capability of the linker, so I have to study a different approach, like it or not.
I don't see it as a limitation when a linker behaves like 99+% of all linkers.
Especially since most companies have an explicit or implicit policy that boot loaders must be separately version-controlled. And separately validated. And separately integrity-checked. All trivial when separate source code produces a separate hex file.
And I don't see much need for studying to remove the end line from the intel-hex file with the boot loader and then do a trivial concatenation of this hex file with the hex file for the application to get a merged binary suitable for factory programming.
When developing, I don't need to download any boot loader - it's already in the board. And the JTAG debugger would normally not need any boot loader to be there, since init scripts can duplicate boot loader state changes.