From: Corinna Vinschen <vinschen@redhat.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: newlib@sourceware.org
Subject: Re: [PATCH] [RFC] newlib: libc: start manual appendix to hold various ABI constants
Date: Tue, 23 Jan 2024 10:15:29 +0100 [thread overview]
Message-ID: <Za-DsWYYd0-iD-Iv@calimero.vinschen.de> (raw)
In-Reply-To: <20231227072512.17179-1-vapier@gentoo.org>
On Dec 27 02:25, Mike Frysinger wrote:
> The newlib errno values end up being exposed way beyond newlib itself,
> so it can be helpful to have a reference of the names & values of them
> all. When using a GNU stack, the errno values might be shared across
> all of them without any translation layers.
>
> Consider:
> * user's code
> * GNU newlib (libc)
> * GNU libgloss (OS bindings)
> * GNU simulator (syscall handler)
>
> When the user program tries to open a file that doesn't exist, it will
> call through newlib -> libgloss -> sim. How is the error code handled ?
> The user program relies on newlib's ENOENT constant. If newlib & libgloss
> don't agree on this value, then libgloss has to maintain a mapping of the
> different constants {"EAGAIN", NEWLIB_EAGAIN, LIBGLOSS_EAGAIN}. No one
> does this of course -- libgloss just uses newlib's values directly. If
> libgloss & the OS don't agree on this value, then libgloss again has to
> maintain a mapping of {"EAGAIN", NEWLIB_EAGAIN, OS_EAGAIN}. No one does
> this with the GNU simulator -- it returns newlib's values directly. The
> simulator definitely has to maintain a mapping of the target's EAGAIN
> values and whatever OS it is running on. Having this be documented all
> the way down is important so people writing simulator ports know what
> values to use.
>
> People implementing a minimal bootloader environment can easily be in the
> same boat -- they are trying to glue one world (e.g. Das U-Boot's machine
> independent API runtime) with another world (e.g. libgloss), and that will
> need to maintain the mapping of values in order for the programs to run
> unmodified.
>
> Start an appendix in the libc manual to hold these constants. These pages
> are automatically generated using the preprocessor and a script from the
> GNU simulator project. If people are amenable to this direction, I can
> port that script over to newlib & strip it down, and also add a few more
> appendix chapters for other important ABI constants (e.g. signals).
> ---
> newlib/Makefile.in | 281 +++++-----
> newlib/libc/errno/Makefile.inc | 3 +
> newlib/libc/errno/constants.tex | 349 ++++++++++++
> newlib/libc/libc.texi | 26 +
> newlib/libc/machine/cris/Makefile.inc | 3 +
> newlib/libc/machine/cris/constants-errno.tex | 541 +++++++++++++++++++
> newlib/libc/machine/spu/Makefile.inc | 3 +
> newlib/libc/machine/spu/constants-errno.tex | 517 ++++++++++++++++++
> 8 files changed, 1584 insertions(+), 139 deletions(-)
> create mode 100644 newlib/libc/errno/constants.tex
> create mode 100644 newlib/libc/machine/cris/constants-errno.tex
> create mode 100644 newlib/libc/machine/spu/constants-errno.tex
I like the idea in general. What I'm a bit put off by are the
machine-specific lists. Ideally they should only contain those values
which differ from the values defined upstream, that is, the values in
newlib/libc/include/sys/errno.h. But I'd understand if that's too
complicated.
Corinna
prev parent reply other threads:[~2024-01-23 9:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-27 7:25 Mike Frysinger
[not found] ` <BN2P110MB15445C61D8D69733C10DA4D99A9CA@BN2P110MB1544.NAMP110.PROD.OUTLOOK.COM>
2023-12-30 1:17 ` FW: " C Howland
2023-12-30 5:03 ` Mike Frysinger
2024-01-23 21:05 ` brian.inglis
2024-01-24 4:37 ` Mike Frysinger
2024-01-23 9:15 ` Corinna Vinschen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Za-DsWYYd0-iD-Iv@calimero.vinschen.de \
--to=vinschen@redhat.com \
--cc=newlib@sourceware.org \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).