From: Willy Tarreau <w@1wt.eu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>,
Warner Losh <imp@bsdimp.com>, Sven Schnelle <svens@linux.ibm.com>
Subject: [PATCH 0/6] pending bug fixes for nolibc
Date: Mon, 9 Jan 2023 08:54:36 +0100 [thread overview]
Message-ID: <20230109075442.25963-1-w@1wt.eu> (raw)
Hello Paul,
please consider the current patch series for merging into your fixes queue.
The intent is to get them before 6.2, then backported where relevant.
It addresses the following bugs:
- fd_set was incorrectly defined as arrays of u32 instead of long,
which breaks BE64. Fix courtesy of Sven Schnelle.
- S_ISxxx macros were incorrectly testing the bits after applying them
instead of applying S_ISFMT to the value. Fix from Warner Losh.
- the mips code was randomly broken due to an unprotected "noreorder"
directive in the _start code that would prevent the assembler from
filling delayed slots, and randomly leaving other instructions there
- since the split of the single include file into multiple files, we're
implicitly refraining from including some which are not explicitly
added in the code. It causes build failures when such files contain
definitions for functions that may be used e.g. by libgcc, such as
raise() or memset(), which are often called only by a few archs at
certain optimization levels only.
- gcc 11.3 in ARM thumb2 mode at -O2 was able to recognize a memset()
construction inside the memset() definition, and it replaced it with
a call to... memset(). We cannot impose to userland to build with
-ffreestanding so the introduction of an empty asm() statement in
the loop was enough to stop this.
- most of the O_* macros were wrong on RISCV because their octal value
was used as a hexadecimal one when the platform was introduced. This
was revealed by the selftest breaking in getdents64().
The series was tested on x86_64, i386, armv5, armv7, thumb1, thumb2,
mips and riscv, all at -O0, -Os and -O3. This is based on the "nolibc"
branch of your linux-rcu tree. Do not hesitate to let me know if you
prefer that I rebase it on a different one.
Thank you!
Willy
---
Sven Schnelle (1):
nolibc: fix fd_set type
Warner Losh (1):
tools/nolibc: Fix S_ISxxx macros
Willy Tarreau (4):
tools/nolibc: restore mips branch ordering in the _start block
tools/nolibc: fix missing includes causing build issues at -O0
tools/nolibc: prevent gcc from making memset() loop over itself
tools/nolibc: fix the O_* fcntl/open macro definitions for riscv
tools/include/nolibc/arch-mips.h | 2 +
tools/include/nolibc/arch-riscv.h | 14 +++----
tools/include/nolibc/ctype.h | 3 ++
tools/include/nolibc/errno.h | 3 ++
tools/include/nolibc/signal.h | 3 ++
tools/include/nolibc/stdio.h | 3 ++
tools/include/nolibc/stdlib.h | 3 ++
tools/include/nolibc/string.h | 8 +++-
tools/include/nolibc/sys.h | 2 +
tools/include/nolibc/time.h | 3 ++
tools/include/nolibc/types.h | 70 ++++++++++++++++++-------------
tools/include/nolibc/unistd.h | 3 ++
12 files changed, 79 insertions(+), 38 deletions(-)
--
2.35.3
next reply other threads:[~2023-01-09 7:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 7:54 Willy Tarreau [this message]
2023-01-09 7:54 ` [PATCH 1/6] nolibc: fix fd_set type Willy Tarreau
2023-01-09 7:54 ` [PATCH 2/6] tools/nolibc: Fix S_ISxxx macros Willy Tarreau
2023-01-09 7:54 ` [PATCH 3/6] tools/nolibc: restore mips branch ordering in the _start block Willy Tarreau
2023-01-09 7:54 ` [PATCH 4/6] tools/nolibc: fix missing includes causing build issues at -O0 Willy Tarreau
2023-01-09 7:54 ` [PATCH 5/6] tools/nolibc: prevent gcc from making memset() loop over itself Willy Tarreau
2023-01-09 7:54 ` [PATCH 6/6] tools/nolibc: fix the O_* fcntl/open macro definitions for riscv Willy Tarreau
2023-01-09 19:11 ` [PATCH 0/6] pending bug fixes for nolibc Paul E. McKenney
2023-01-10 7:28 ` Willy Tarreau
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=20230109075442.25963-1-w@1wt.eu \
--to=w@1wt.eu \
--cc=imp@bsdimp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=svens@linux.ibm.com \
/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 NNTP newsgroup(s).