Re: [QUERY] Understanding call flow from stdio to stub syscalls in newlib (nvptx)
| 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-----