Re: [QUERY] Understanding call flow from stdio to stub syscalls in newlib (nvptx)

[email protected]
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On 13/06/2025 15:21, Arijit Kumar Das wrote:
> Hi,
> 
> I’m a new contributor to newlib, currently working on modifying the
> stub system calls in
> newlib/libc/machine/nvptx/misc.c as part of my Google Summer of Code
> 2025 project
> under GCC. The goal is to implement a memory-resident filesystem for
> nvptx targets.
> 
> To facilitate this, I’d like to better understand how higher-level
> stdio functions (e.g., fopen())
> resolve down to these low-level syscall stubs like open().
> Specifically, I’m looking for a
> rough call flow or trace of function calls (e.g, fopen() --> open()),
> and any relevant source
> files beyond misc.c that would be helpful for understanding this
> linkage within newlib.
> 
> Any guidance or references would be greatly appreciated.
> 
> Thanks and regards,
> Arijit Kumar Das

The sources for newlib are online-browsable via 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git and the 
documentation for what is required for each FILE-based call at 
https://sourceware.org/newlib/ although the latter only tells you about 
the latest newlib release whereas your platform may be using an earlier 
one so checking the sources for the release in use can save some 
headaches. (I've implemented the FD-based APIs on newlib routing to 
FatFS, LittleFS & lwIP simultaneously in the past and the web site has 
led me astray sometimes!)

But provided you follow the POSIX specifications for the low level APIs 
(open(), close(), read(), write(), isatty(), lseek(), fstat() at least 
and maybe dirent.h, stat() and unlink()) as closely as you can given the 
limitations of your filesystem then newlib will be happy and you don't 
need to nor should you make assumptions about how exactly newlib uses 
them to implement the higher level APIs.

-- 
Sam Edge
OpenPGP_0xE6200DE0C92CEC06_and_old_rev.asc (application/pgp-keys, 1.1 KB)
-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEZRUsPRYJKwYBBAHaRw8BAQdAJJIM3nIi/0AlR8YNKSbIucsGaX/dfmp7oBLT
C6Di1UHNIlNhbSBFZGdlIDxzYW0uZWRnZS5uZXdsaWJAZ214LmNvbT7CjwQTFggA
NxYhBNdZ6mE651AobMQsM+YgDeDJLOwGBQJlFSw9BQkSzAMAAhsDBAsJCAcFFQgJ
CgsFFgIDAQAACgkQ5iAN4Mks7AY5JAEApAAHuSOu21+x2uLpSmN2mi/yCAS5cGpy
OYfUVJ6kTloA+wVEhOFeeRAl8jQCEw0QOki/+7hGW1N9z3qG+ND14vUIzjgEZRUs
PRIKKwYBBAGXVQEFAQEHQKiCziMIYxB6C419NstmKUgH6/TQ0DmtAqBhhBjEC9UZ
AwEIB8J+BBgWCAAmFiEE11nqYTrnUChsxCwz5iAN4Mks7AYFAmUVLD0FCRLMAwAC
GwwACgkQ5iAN4Mks7AbuRgD+IQL27tV1vjSXHL0uKObS+pcZETsH3FA1LwR8cZw3
3x4A/iqA04meXfecoyi3lr5O20NsWSsucpzazIAH8hYzrT0OxjMEZRUsPBYJKwYB
BAHaRw8BAQdAfTvjyHM/Oum9+RhQ4sczPMQ3qZ1rvy+R7xOgV5fIpWLCeAQgFggA
IBYhBNT+XGXKdDxOakWZc0GqKxqf/+MDBQJlFTKLAh0AAAoJEEGqKxqf/+MDuTEA
/0gy4cxdzIE7hL3ehbcjmkpqc0CHnkbYPnUsweMxZAcTAQCKWOy7f66LyqsImOHg
EBCQ+ttUK1xX+fl7wtoeeG/RBc44BGUVLDwSCisGAQQBl1UBBQEBB0DNsJdpv0iR
5XIyxFG8OSqDQojGSVmaSCFwiUXjRxwPDAMBCAfCfgQYFggAJhYhBNT+XGXKdDxO
akWZc0GqKxqf/+MDBQJlFSw8BQkSzAMAAhsMAAoJEEGqKxqf/+MDY84BALkIC2Ao
5uqJlP2hIfRyAlDO3CiGB+pcoPqfL+yTLFQzAP46VlC/2Ll0LI3tBmYZ0aDLu0N+
bN3b0msL+HioGuigBg==
=R8EG
-----END PGP PUBLIC KEY BLOCK-----
OpenPGP_signature.asc (application/pgp-signature, 236 B)
-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTXWephOudQKGzELDPmIA3gySzsBgUCaExDxgUDAAAAAAAKCRDmIA3gySzsBkh9
AP0Wau3iC38cC636DvFn+GO0jPBHU/fRS8abYAw7T/M0sgEA/n+L7Q7S7BIJHkJUFCNwhT/qDsWl
vYAPDKUUgc1Krw4=
=YvC2
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.