Undefined References to System Calls in ARM Cortex-M0+ Cross-Compilation
When attempting to cross-compile a simple "hello world" program for an ARM Cortex-M0+ target using the GCC ARM embedded toolchain, the linker fails with multiple undefined references to system calls such as _exit, _sbrk, _write, _close, _lseek, _read, _fstat, and _isatty. These errors indicate that the linker is unable to resolve symbols for low-level system functions that are typically provided by a C runtime library or a system-specific implementation. The issue arises because the default newlib C library expects these system calls to be implemented by the target environment, but they are missing or not properly linked.
The root cause of these errors lies in the absence of a suitable system call implementation for the target platform. The ARM Cortex-M0+ is a bare-metal microcontroller, and unlike a full-fledged operating system, it does not provide these system calls out of the box. The linker is attempting to link against the standard C library (libc.a), which relies on these system calls for basic functionality such as memory management, file I/O, and process control. Without a proper implementation, the linker cannot resolve these symbols, leading to the observed errors.
Missing or Incorrectly Specified System Library (nosys)
The user attempted to resolve the issue by specifying the -l=nosys flag, which is intended to link against a minimal system library that provides stubs for these system calls. However, the linker error cannot find -l suggests that the nosys library is either missing or incorrectly specified. The nosys library is part of the ARM GCC toolchain and provides dummy implementations of system calls that allow programs to link successfully but will fail at runtime if the system calls are invoked. This library is essential for bare-metal development where no operating system is present.
The error cannot find -l indicates that the linker is unable to locate the nosys library. This could be due to an incorrect path specification, a missing library file, or an issue with the toolchain installation. The nosys library should be located in the lib directory of the ARM GCC toolchain installation, typically under a subdirectory corresponding to the target architecture (e.g., thumb/v6-m/nofp for Cortex-M0+).
Troubleshooting Steps and Solutions for Resolving Linker Errors
Step 1: Verify the Toolchain Installation
Ensure that the ARM GCC toolchain is correctly installed and that all necessary libraries, including nosys, are present. The toolchain should include the following directories:
bin: Contains the cross-compiler executables (e.g.,arm-none-eabi-gcc).lib: Contains the standard C libraries and system libraries (e.g.,libc.a,libnosys.a).include: Contains the header files for the standard C library and other libraries.
To verify the installation, navigate to the lib directory and check for the presence of libnosys.a in the appropriate subdirectory (e.g., thumb/v6-m/nofp). If the library is missing, reinstall the toolchain or manually download and place the library in the correct location.
Step 2: Correctly Specify the System Library
When linking the program, explicitly specify the nosys library using the -lnosys flag. Ensure that the flag is correctly formatted and that there are no typos or syntax errors. For example:
arm-none-eabi-gcc -o hello -mcpu=cortex-m0plus -lnosys hello.c
This command tells the linker to include the nosys library, which provides stubs for the missing system calls.
Step 3: Implement Custom System Calls (Optional)
If the nosys library is not sufficient for your needs, you can implement custom system calls tailored to your target hardware. This involves writing your own versions of the required system call functions (e.g., _exit, _sbrk, _write) and linking them with your program. For example:
void _exit(int status) {
// Custom implementation for _exit
while (1); // Infinite loop to halt execution
}
void* _sbrk(int incr) {
// Custom implementation for _sbrk
extern char _end; // Defined by the linker script
static char* heap_end = &_end;
char* prev_heap_end = heap_end;
heap_end += incr;
return prev_heap_end;
}
These implementations should be placed in a separate source file and compiled with your program. Link the resulting object file with your application to resolve the undefined references.
Step 4: Use a Linker Script for Memory Management
For bare-metal systems, a linker script is often required to define memory regions and allocate sections such as .text, .data, and .bss. The linker script can also specify the entry point and stack size. Ensure that your project includes a linker script appropriate for the Cortex-M0+ target. For example:
ENTRY(Reset_Handler)
MEMORY {
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 8K
}
SECTIONS {
.text : {
*(.text*)
*(.rodata*)
*(.glue_7*)
*(.glue_7t*)
*(.eh_frame*)
KEEP(*(.init))
KEEP(*(.fini))
} > FLASH
.data : {
*(.data*)
} > RAM AT > FLASH
.bss : {
*(.bss*)
*(COMMON)
} > RAM
}
This linker script defines memory regions for flash and RAM and specifies how sections should be allocated. Adjust the memory sizes and addresses to match your target hardware.
Step 5: Debugging and Testing
After resolving the linker errors, test the program on the target hardware or in a simulator. Use a debugger to step through the code and verify that the system calls behave as expected. If the program crashes or behaves unexpectedly, revisit the custom system call implementations and ensure they are correctly integrated with the hardware.
By following these steps, you can resolve the linker errors and successfully cross-compile and link programs for the ARM Cortex-M0+ target using the GCC ARM embedded toolchain.
