linux-dev/tools/include/nolibc, branch master

tools/nolibc/string: Fix memcmp() implementation

2022-10-28T22:07:02Z

The C standard says that memcmp() must treat the buffers as consisting of "unsigned chars". If char happens to be unsigned, the casts are ok, but then obviously the c1 variable can never contain a negative value. And when char is signed, the casts are wrong, and there's still a problem with using an 8-bit quantity to hold the difference, because that can range from -255 to +255. For example, assuming char is signed, comparing two 1-byte buffers, one containing 0x00 and another 0x80, the current implementation would return -128 for both memcmp(a, b, 1) and memcmp(b, a, 1), whereas one of those should of course return something positive. Signed-off-by: Rasmus Villemoes Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12

2022-10-28T22:07:02Z

When built at -Os, gcc-12 recognizes an strlen() pattern in nolibc_strlen() and replaces it with a jump to strlen(), which is not defined as a symbol and breaks compilation. Worse, when the function is called strlen(), the function is simply replaced with a jump to itself, hence becomes an infinite loop. One way to avoid this is to always set -ffreestanding, but the calling code doesn't know this and there's no way (either via attributes or pragmas) to globally enable it from include files, effectively leaving a painful situation for the caller. Alexey suggested to place an empty asm() statement inside the loop to stop gcc from recognizing a well-known pattern, which happens to work pretty fine. At least it allows us to make sure our local definition is not replaced with a self jump. The function only needs to be renamed back to strlen() so that the symbol exists, which implies that nolibc_strlen() which is used on variable strings has to be declared as a macro that points back to it before the strlen() macro is redifined. It was verified to produce valid code with gcc 3.4 to 12.1 at different optimization levels, and both with constant and variable strings. In case this problem surfaces again in the future, an alternate approach consisting in adding an optimize("no-tree-loop-distribute-patterns") function attribute for gcc>=12 worked as well but is less pretty. Reported-by: kernel test robot Link: https://lore.kernel.org/r/202210081618.754a77db-yujie.liu@intel.com Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Fixes: 96980b833a21 ("tools/nolibc/string: do not use __builtin_strlen() at -O0") Cc: "Paul E. McKenney" Cc: Alexey Dobriyan Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: make sys_mmap() automatically use the right __NR_mmap definition

2022-08-31T12:17:43Z

__NR_mmap2 was used for i386 but it's also needed for other archs such as RISCV32 or ARM. Let's decide to use it based on the __NR_mmap2 definition as it's not defined on other archs. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: fix build warning in sys_mmap() when my_syscall6 is not defined

2022-08-31T12:17:43Z

We return -ENOSYS when there's no syscall6() operation, but we must cast it to void* to avoid a warning. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: make argc 32-bit in riscv startup code

2022-08-31T12:17:43Z

The "ld a0, 0(sp)" instruction doesn't build on RISCV32 because that would load a 64-bit value into a 32-bit register. But argc 32-bit, not 64, so we ought to use "lw" here. Tested on both RISCV32 and RISCV64. Cc: Pranith Kumar Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: add a help target to list supported targets

2022-06-20T16:43:19Z

The "help" target simply presents the list of supported targets and the current set of variables being used to build the sysroot. Since the help in tools/ suggests to use "install", which is supported by most tools while such a target is not really relevant here, an "install" target was also added, redirecting to "help". Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: make the default target build the headers

2022-06-20T16:43:19Z

The help in "make -C tools" enumerates nolibc as a valid target so we must at least make it do something. Let's make it do the equivalent of "make headers" in that it will prepare a sysroot with the arch's headers, but will not install the kernel's headers. This is the minimum some tools will need when built with a full-blown toolchain anyway. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: fix the makefile to also work as "make -C tools ..."

2022-06-20T16:43:19Z

As reported by Linus, the nolibc's makefile is currently broken when invoked as per the documented method (make -C tools nolibc_), because it now relies on the ARCH and OUTPUT variables that are not set in this case. This patch addresses this by sourcing subarch.include, and by presetting OUTPUT to the current directory if not set. This is sufficient to make the commands work both as a standalone target and as a tools/ sub-target. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc/stdio: Add format attribute to enable printf warnings

2022-06-20T16:43:19Z

When we use printf and fprintf functions from the nolibc, we don't get any warning from the compiler if we have the wrong arguments. For example, the following calls will compile silently: ``` printf("%s %s\n", "aaa"); fprintf(stdout, "%s %s\n", "xxx", 1); ``` (Note the wrong arguments). Those calls are undefined behavior. The compiler can help us warn about the above mistakes by adding a `printf` format attribute to those functions declaration. This patch adds it, and now it yields these warnings for those mistakes: ``` warning: format `%s` expects a matching `char *` argument [-Wformat=] warning: format `%s` expects argument of type `char *`, but argument 4 has type `int` [-Wformat=] ``` [ ammarfaizi2: Simplify the attribute placement. ] Signed-off-by: Alviro Iskandar Setiawan Signed-off-by: Ammar Faizi Acked-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc/stdlib: Support overflow checking for older compiler versions

2022-06-20T16:43:19Z

Previously, we used __builtin_mul_overflow() to check for overflow in the multiplication operation in the calloc() function. However, older compiler versions don't support this built-in. This patch changes the overflow checking mechanism to make it work on any compiler version by using a division method to check for overflow. No functional change intended. While in there, remove the unused variable `void *orig`. Link: https://lore.kernel.org/lkml/20220330024114.GA18892@1wt.eu Suggested-by: Willy Tarreau Cc: Alviro Iskandar Setiawan Signed-off-by: Ammar Faizi Acked-by: Willy Tarreau Reviewed-by: Alviro Iskandar Setiawan Signed-off-by: Paul E. McKenney