5
\$\begingroup\$

What is the role of syscalls.c file in GNU ARM(STM32 for instance) based projects? I found 2 ways of successfully building the project

  1. Delete syscalls.c and include -specs=nosys.specs in the linker flags

  2. Simply include syscalls.c

What is the fundamental difference between these two methods? What is the importance of system calls in a non-os environment like microcontroller? If it is used for implementing system-level functions used by printf, scanf, etc. then who is calling these function(because I am not using any of these functions in my code)?

Edit:- As an experimental step, I deleted syscalls.c and added -specs=nosys.specs to make the linker happy then I wrote a simple malloc program to check whether it is working or not. To my surprise, it is giving the expected output. How did the malloc function work without the _sbrk definition in syscalls.c? I checked the startup file but it has only a few functions like copying data from flash to SRAM during startup, zeroing out .bss section, etc. Can I assume that it has to do something with C Runtime Library? If so where is it located?

P.S - I am using System Workbench for STM32 & STM32F4Nucleo board for this particular example

\$\endgroup\$

2 Answers 2

Reset to default
6
\$\begingroup\$

Some reasons:

  1. printf uses _write and _read. You can write your own ones for example if you want to redirect output to SWO
  2. malloc & friends use _sbrk. Bur I would rather avoid dynamic allocation in the limited resources implementations. This version of _sbrk is very poor (it assumes that the stack is at the largest addresses and heap is just before etc etc).
  3. The rest of the functions are stubs just to make the compiler C standard conformant. They do nothing.
\$\endgroup\$
4
  • 2
    \$\begingroup\$ The malloc function is working fine even after deleting syscalls.c so I am not able to connect it with your point No.2. I have edited the question for more clarity. \$\endgroup\$
    – Supreeth
    Sep 25, 2019 at 9:35
  • 1
    \$\begingroup\$ @Supreeth You use (in the second case) the libraries as defined in the specs file. Google about the specs gcc files. \$\endgroup\$
    – 0___________
    Sep 25, 2019 at 9:52
  • 2
    \$\begingroup\$ specs file was the missing piece of the puzzle. So I can conclude that nosys.specs is a spec file used to tell the GCC to link with a different version of the library(usually comes with embedded c library such as newlibc, nanolibc, etc. which contains definition of _write, _sbrk, etc.) and the lib spec string inside nosys.specs is responsible for that. Please correct me if I am wrong. \$\endgroup\$
    – Supreeth
    Sep 26, 2019 at 5:48
  • 1
    \$\begingroup\$ You are right. Thats exactly how it works \$\endgroup\$
    – 0___________
    Sep 26, 2019 at 7:12
2
\$\begingroup\$

Adding to @0___________ answer, the assert() function from <assert.h> will ultimately call the void _exit (int status) function in syscall.c.

enter image description here

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.