Decide on nosys.specs or manually-created syscall stubs

[lightspot21]

Right now, we are omitting --specs=nosys.specs, and this omission technically leaves undefined any symbols corresponding to syscalls required by the compiled version of newlib packaged with arm-none-eabi-gcc, such as _exit, _close or more critically _sbrk for dynamic memory allocation.

Adding --gc-sections on the toolchain file seems to work (as in compiles and links without any build errors), which makes sense given the trivial test project (it doesn't actually use any stdlib constructs, thus the missing references to those symbols get cleaned), but what if someone uses a construct that behind the scenes needs the stdlib (especially with C++ stuff)? Will the linker complain? I think yes, but this must be tested.

Merely including nosys.specs is not the easy solution to this, however, as nosys.specs implements _sbrk (which we don't want to use).

[kongr45gpen]

Don't overcomplicate things. Define --specs=nosys.specs, don't mess with system definitions that already work.

If you really want to disable heap allocation, either do a manual search for calls to _sbrk, or redefine it so that it always returns NULL (newlib defines it as weak anyway), or find a way to poison it.

Please don't spend any time reinventing the wheel and thinking about how/where/why to implement standard system calls, this is not a dual-core project that is supported by a full room of low-level developers.

[lightspot21]

Oh hey there @kongr45gpen ! Just to be clear, I'm not trying to overcomplicate an already complicated situation; all I'm trying to do is to somehow document/justify all settings used on the setup, in order for it to be explainable.

I have no problem with the use of nosys.specs itself; in fact I'd prefer using it as it's a tested thing that comes with the compiler. The only concern I have is that it forces me to use --gc-sections to clean up undefined symbols (which, in my mind, is a bit of a hack and not easy to explain to a new developer - using an optimization option just to make your stdlib link correctly).

That said, I found out that I can provide definitions for the missing symbols that nosys.specs requires (__bss_start__/__bss_end__/end) through the command line. Since they are already defined as _sbss/_ebss in the linker script, I can alias them via the linker option -Wl,--defsym, which should work and be easier to comprehend. What do you think?

By the way, thanks for the poisoning trick, it's really nice and I didn't know of it!