Newlib Digest, Vol 64, Issue 17

[Arijit Kumar Das]

Hi Sam,

Thank you for your guidance! This was really very helpful to
me as a new contributor.

Regards,
Arijit


On Sat, Jun 14, 2025 at 5:30 PM <newlib-request@sourceware.org> wrote:
>
> Send Newlib mailing list submissions to
>         newlib@sourceware.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://sourceware.org/mailman/listinfo/newlib
> or, via email, send a message with subject or body 'help' to
>         newlib-request@sourceware.org
>
> You can reach the person managing the list at
>         newlib-owner@sourceware.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Newlib digest..."
> Today's Topics:
>
>    1. [QUERY] Understanding call flow from stdio to stub syscalls
>       in newlib (nvptx) (Arijit Kumar Das)
>    2. Re: [QUERY] Understanding call flow from stdio to stub
>       syscalls in newlib (nvptx) (sam.edge.newlib@gmx.com)
>
>
>
> ---------- Forwarded message ----------
> From: Arijit Kumar Das <arijitkdgit.official@gmail.com>
> To: newlib@sourceware.org
> Cc:
> Bcc:
> Date: Fri, 13 Jun 2025 19:51:58 +0530
> Subject: [QUERY] Understanding call flow from stdio to stub syscalls in newlib (nvptx)
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: sam.edge.newlib@gmx.com
> To: newlib@sourceware.org
> Cc:
> Bcc:
> Date: Fri, 13 Jun 2025 16:29:09 +0100
> Subject: Re: [QUERY] Understanding call flow from stdio to stub syscalls in newlib (nvptx)
> 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