Customized C library startup code and access to C library functions
If you build an application with customized startup code, you must either avoid functions that require initialization or provide the initialization and low-level support functions.
When building an application without the C library, if you create an
application that includes a
main() function, the linker
automatically includes the initialization code necessary for the execution environment.
There are situations where this is not desirable or possible. For example, a system running
a Real-Time Operating System (RTOS) might have its execution
environment configured by the RTOS startup code.
You can create an application that consists of customized startup code and still use many of the library functions. You must either:
Avoid functions that require initialization.
Provide the initialization and low-level support functions.
The functions you must re-implement depend on how much of the library functionality you require:
If you want only the compiler support functions for division, structure copy, and floating-point arithmetic, you must provide
__rt_raise(). This also enables very simple library functions such as those in errno.h, setjmp.h, and most of string.h to work.
If you call
setlocale()explicitly, locale-dependent functions are activated. This enables you to use the
sscanf(), and the functions in ctype.h.
armclang uses full IEEE math by default, therefore
__rt_fp_status_addr()is always required.
Implementing high-level input/output support is necessary for functions that use
fputs(). The high-level output functions depend on
ferror(). The high-level input functions depend on
Implementing these functions and the heap enables you to use almost the entire library.