Usage of __assert_func in standard library

[Alex Tarasov]

Dear developers of  Newlib,

I think we have a bit of an issue concerning usage of *__assert_func *function
in the current version of the standard library.

Let me describe what I've stumbled upon. I'm using "Arm GNU Toolchain" for
embedded software development. This toolchain is shipped with Newlib's
standard library. Up until recently I've been using the old version of the
toolchain (released in 2019). When I tried to update to the newer one, I
faced a problem. My project is being built without any errors or warnings
with the old toolchain, but when I try to build it with the newer version I
get these errors:
ld.exe: PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-closer.o):
in function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-lseekr.o):
in function `_lseek_r':
lseekr.c:(.text._lseek_r+0x14): undefined reference to `_lseek'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-readr.o):
in function `_read_r':
readr.c:(.text._read_r+0x14): undefined reference to `_read'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-writer.o):
in function `_write_r':
writer.c:(.text._write_r+0x14): undefined reference to `_write'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-fstatr.o):
in function `_fstat_r':
fstatr.c:(.text._fstat_r+0x12): undefined reference to `_fstat'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-isattyr.o):
in function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-signalr.o):
in function `_kill_r':
signalr.c:(.text._kill_r+0x12): undefined reference to `_kill'
PathToCompiler/ld.exe:
PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a(libc_a-signalr.o):
in function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'

The analysis of cross reference table in the .map file showed me the source
of these errors. Somehow, in the newer toolchain functions from the
standard library (*strtod* in my case) call *"__assert_func"* which in turn
lead to various system calls. I downloaded the latest Newlib version on the
"main" branch and saw this code in the *newlib/libc/stdlib/mprec.h* file:

#define eBalloc(__reent_ptr, __len) ({ \
   void *__ptr = Balloc(__reent_ptr, __len); \
   if (__ptr == NULL) \
     __assert_func(__FILE__, __LINE__, (char *)0, "Balloc succeeded"); \
   __ptr; \
   })

According to *git log* this *eBalloc* macro was introduced in commit
with f88aece242178ff0c187d56e34a79645fbc44a23
hash on October 4th 2019. This leads to several functions in the standard
library calling *__assert_func* inside them. Standard definition of this
function in *newlib/libc/stdlib/assert.c* calls *abort* and *fiprintf*
functions
which in turn drag a lot of system functions (see error log that I
mentioned above).

This leads to several issues:

   - If I want to use some functions from the standard library (like
   *strtod*) but I don't want any system calls, I need to redefine
   *__assert_func* in my project. I have to do it even if I don't use
   assert's anywhere in my own code.
   - There is a project where I use <assert.h> and my own
implementation of *__assert_func.
   *I expect that when I build my project with NDEBUG macro defined
   (release configuration), I would not see any calls to that function. That
   is not the case if any function from Newlib's standard library that uses
   *eBalloc* macro gets linked.

I think this behaviour is too implicit and needs to be fixed. I suggest
removing *__assert_func* from *eBalloc* macro or making some other changes
to Newlib that will get rid of the mentioned issues.

I would really appreciate any feedback on this matter.

Kind regards,
Alexander Tarasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20231115/6c6b5fea/attachment-0001.htm>