[riot-devel] Unimplemented syscalls in RIOT

Juan Ignacio Carrano j.carrano at fu-berlin.de
Thu May 24 11:42:48 CEST 2018


Hello RIOTers,

I have run into some issues while working on lua support, involving 
missing system calls and linker errors while trying to use C standard 
functions, such as rename() and clock().

For example: A program calls rename(). Rename is defined by newlib and 
calls link(), which calls _link_r (the reentrant version), which is not 
defined, so linking fails. A similar thing happens with clock() (calls 
times() which calls _times_r).

The immediate reason is that, as of PR #8795, RIOT is linked with 
-lnosys, meaning newlib no longer provide stubs. Of course, for us this 
is a good thing (that's why the PR got merged). The problems arise when 
we try to compile packages, that is, code that we don't "control" and 
that we'd like to modify as little as possible.

sys/newlib_syscalls_default/syscalls.c implements several stubs. For 
some functions it implements the right thing if the correct module is 
enable, like filesystem calls if we have VFS.

There are several options for fixing this problem of missing syscalls:

1. Patch the packages to avoid those functions. It's a lot of work, and 
does not add any value to RIOT.
2. Add empty stubs that always fail (and set errno to ENOSYS). This 
makes programs compile, but then it may run into errors at runtime and 
the developer will be probably unaware that the code is using 
unsupported functionality.
3. Add empty stubs as part of a module, so that the fake functions must 
be explicitly included.
4. Make other riot modules provide the standard C interface. For 
example, xtimer may provide for clock().

Going back to my case of Lua, I initially thought of doing (2), but 
after a conversation with José Alamos he convinced me it's not a good 
idea. I'd suggest doing (3) and (4), that is, having parts of the 
standard library be implemented by the relevant RIOT module (clock() in 
xtimer, link()/rename() in vfs) while also having a stub modules for 
those cases in which it is acceptable to have unimplemented functionality.

I look forward to you comments.

Regards

Juan.


More information about the devel mailing list