gcc-arm-none-eabi 11.3 "is not implemented and will always fail"

Question

I'm working on a bare-metal STM32 project, compiling on a Linux x64 host.

After upgrading my toolchain from gcc-arm-none-eabi-11.2-2022.02 to arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi, I get the following linker warnings:

warning: _close is not implemented and will always fail
warning: _fstat is not implemented and will always fail
warning: _getpid is not implemented and will always fail
warning: _isatty is not implemented and will always fail
warning: _kill is not implemented and will always fail
warning: _lseek is not implemented and will always fail
warning: _open is not implemented and will always fail
warning: _read is not implemented and will always fail
warning: _write is not implemented and will always fail

More comprehensively, I get this:

~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg.a(libc_a-closer.o): in function `_close_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/closer.c:47: warning: _close is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(libc_a-fstatr.o): in function `_fstat_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/fstatr.c:55: warning: _fstat is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(libc_a-signalr.o): in function `_getpid_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/signalr.c:83: warning: _getpid is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(libc_a-isattyr.o): in function `_isatty_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/isattyr.c:52: warning: _isatty is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(libc_a-signalr.o): in function `_kill_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/signalr.c:53: warning: _kill is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg.a(libc_a-lseekr.o): in function `_lseek_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/lseekr.c:49: warning: _lseek is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(libc_a-openr.o): in function `_open_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/openr.c:50: warning: _open is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg.a(libc_a-readr.o): in function `_read_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/readr.c:49: warning: _read is not implemented and will always fail
~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: ~/dev_tools/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libg.a(libc_a-writer.o): in function `_write_r':
/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/newlib/libc/reent/writer.c:49: warning: _write is not implemented and will always fail

Other than that, the project seems to compile fine. Reading the release note (available here), I can't see what could cause this.

1. What change caused this?
2. Can I disregard these warnings? It looks like system calls, so I guess I can?
3. If so, can they be silenced?

Answer 1

The warnings you encountered were placed in syscalls implementation of libnosys (e.g. see close.c, and relevant warning.h. At some point, you link against libnosys - either by

• -lnosys link flag (common in Makefiles, generated by STM32CubeMX),
• --specs=nosys.specs compile/link flag

The developers used a neat trick to embed warning messages into object files, using .gnu.warning.SYMBOL_NAME - Unfortunately I couldn't find official documentation, but you can read more about it here, and here.

The reason you see these warnings is that those syscalls are referenced "somewhere"... It might be a stray printf/putchar in your code, exit(), rand(), or some usage in libc itself.

Regarding the severity of the warnings

In freestanding, bare metal environments it is absolutely normal to use dummy syscalls, as we don't expect to interact with the operating system. If you use an RTOS on your platform, there is probably a dedicated syscalls implementation waiting for you. So there is probably nothing to worry about this warning. I think that the warning message itself is a little bit misleading - by "fail" it means "do nothing and return error status", which is well-defined behavior that should not lead to abnormal program execution.

Side note: I checked libnosys.a from 10-2020-q4-major release of arm-none-eabi with objdump, and it didn't have those warning symbols.

Finally, how to get rid of the messages

As others mentioned, in freestanding environment, you can provide your own dummy syscalls, and don't link against libnosys. I searched through ld documentation and source code, and didn't find a linker option to suppress this warning.

Note that if you rely on dynamic memory allocation using malloc in C, or new in C++, your implementation of _sbrk must actually work (more info here), otherwise you may enter "debugging so funny that it lasts for weeks" zone.

Funnily enough, libnosys's implementation of _sbrk works AND doesn't have embedded warning symbol. I strongly recommend using it, unless you need to allocate heap on external RAM, etc.

The added benefit of using libnosys is the fact that you don't need to write your custom syscalls in every project you make, which could be tiresome and error-prone.

TL;DR

Having said that, there is actually a method to get rid of the warnings from libnosys permanently: Look for libnosys.a in your toolchain directory (in arm-none-abi case there will one for each architecture and float ABI), and delete .gnu.warning symbols from archives using:

arm-none-eabi-objcopy -w -R .gnu.warning.* libnosys.a

Note that this will irreversibly modify your toolchain files. Most likely in intended, and non-harmful way, but still. Use with caution.

If you use CMake to build your project I would consider creating PRE_LINK command that copies relevant libnosys, strips it of warnings, and link with it instead.

Answer 2

The library supplied with gcc-arm-none-eabi is called 'newlib'. You can download a copy from git://sourceware.org/git/newlib-cygwin.git. It has tags and you can determine the specific version released with your compiler and get the tagged version.

For example, syscalls.c is one implementation. The Libc stubs document contains functions to implement. However, you may wonder why you get these warnings. There are various 'C' library function calls, such as srand(), assert(), etc which will drag in the 'C' file libraries. You need to look at a map file and avoid these function calls if you wish to minimize overhead.

I am not sure of your code base and sub-sections of a map file would be helpful. Here you have,

• _open_r
• _close_r
• _read_r

Which are from the 'reent' for re-entrant library. Typically, the re-entrant functions are only needed for an RTOS or desktop operating system. If you have a bare metal single main thread, you do not need these functions. You can not call open() in an interrupt handler with this option :) So, there is really only one context (and a single errno as well). The 're-entrant' functionality is useless. As is .fini sections, embedded devices don't 'shutdown' normally, they reboot.

What change caused this?

You have linked with something (called a function) that brought in file system primitives in the 'C' library.

Can I disregard these warnings?

It depends on your use case. Are you a safety critical system? Generally I would recommend fixing them so the next person is not confused. Most likely if the code follows the path to these functions, something is already wrong/unhandled.

It looks like system calls, so I guess I can?

Not a question?

If so, can they be silenced?

Either avoid the functions or provide alternate implementations that 'do the right thing'. The 'right thing' will depend on your platform.

Here is a list of options when you have linker errors.

1. Change the build options.
2. Provide the library.
3. Provide an alternative library.
4. Avoid the function call/data use.

You can implement your own close_r(), open_r(), and read_r(). For instance, you can use an embedded read-only file system with a linked blob (option 3). Most likely the write is to stderr, so it may not be appropriate (option 4). The option 2 is actually the issue in this case; but it might be fine... it is just the authors of newlib are not sure what the right things is, hence the warning.