kernel/linux.git/tools/include/nolibc/string.h, branch v6.6.131

tools/nolibc: use standard asm statements

2023-06-09T18:46:07+00:00

Most of the code was migrated to C99-conformant __asm__ statements before. It seems string.h was missed. Signed-off-by: Thomas Weißschuh Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: prevent gcc from making memset() loop over itself

2023-01-09T17:36:05+00:00

When building on ARM in thumb mode with gcc-11.3 at -O2 or -O3, nolibc-test segfaults during the select() tests. It turns out that at this level, gcc recognizes an opportunity for using memset() to zero the fd_set, but it miscompiles it because it also recognizes a memset pattern as well, and decides to call memset() from the memset() code: 000122bc : 122bc: b510 push {r4, lr} 122be: 0004 movs r4, r0 122c0: 2a00 cmp r2, #0 122c2: d003 beq.n 122cc 122c4: 23ff movs r3, #255 ; 0xff 122c6: 4019 ands r1, r3 122c8: f7ff fff8 bl 122bc 122cc: 0020 movs r0, r4 122ce: bd10 pop {r4, pc} Simply placing an empty asm() statement inside the loop suffices to avoid this. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc: fix missing includes causing build issues at -O0

2023-01-09T17:36:05+00:00

After the nolibc includes were split to facilitate portability from standard libcs, programs that include only what they need may miss some symbols which are needed by libgcc. This is the case for raise() which is needed by the divide by zero code in some architectures for example. Regardless, being able to include only the apparently needed files is convenient. Instead of trying to move all exported definitions to a single file, since this can change over time, this patch takes another approach consisting in including the nolibc header at the end of all standard include files. This way their types and functions are already known at the moment of inclusion, and including any single one of them is sufficient to bring all the required ones. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc/string: Fix memcmp() implementation

2022-10-28T22:07:02+00:00

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:02+00:00

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/string: Implement `strdup()` and `strndup()`

2022-04-21T00:05:46+00:00

These functions are currently only available on architectures that have my_syscall6() macro implemented. Since these functions use malloc(), malloc() uses mmap(), mmap() depends on my_syscall6() macro. On architectures that don't support my_syscall6(), these function will always return NULL with errno set to ENOSYS. Acked-by: Willy Tarreau Signed-off-by: Ammar Faizi Signed-off-by: Paul E. McKenney

tools/nolibc/string: Implement `strnlen()`

2022-04-21T00:05:46+00:00

size_t strnlen(const char *str, size_t maxlen); The strnlen() function returns the number of bytes in the string pointed to by sstr, excluding the terminating null byte ('\0'), but at most maxlen. In doing this, strnlen() looks only at the first maxlen characters in the string pointed to by str and never beyond str[maxlen-1]. The first use case of this function is for determining the memory allocation size in the strndup() function. Link: https://lore.kernel.org/lkml/CAOG64qMpEMh+EkOfjNdAoueC+uQyT2Uv3689_sOr37-JxdJf4g@mail.gmail.com Suggested-by: Alviro Iskandar Setiawan Acked-by: Willy Tarreau Signed-off-by: Ammar Faizi Signed-off-by: Paul E. McKenney

tools/nolibc/string: do not use __builtin_strlen() at -O0

2022-04-21T00:05:46+00:00

clang wants to use strlen() for __builtin_strlen() at -O0. We don't really care about -O0 but it at least ought to build, so let's make sure we don't choke on this, by dropping the optimizationn for constant strings in this case. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc/string: add strcmp() and strncmp()

2022-04-21T00:05:45+00:00

We need these functions all the time, including when checking environment variables and parsing command-line arguments. These implementations were optimized to show optimal code size on a wide range of compilers (22 bytes return included for strcmp(), 33 for strncmp()). Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

tools/nolibc/string: export memset() and memmove()

2022-04-21T00:05:45+00:00

"clang -Os" and "gcc -Ofast" without -ffreestanding may ignore memset() and memmove(), hoping to provide their builtin equivalents, and finally not find them. Thus we must export these functions for these rare cases. Note that as they're set in their own sections, they will be eliminated by the linker if not used. In addition, they do not prevent gcc from identifying them and replacing them with the shorter "rep movsb" or "rep stosb" when relevant. Signed-off-by: Willy Tarreau Signed-off-by: Paul E. McKenney

kernel/linux.git/tools/include/nolibc/string.h, branch v6.6.131

tools/nolibc: use standard __asm__ statements

tools/nolibc: prevent gcc from making memset() loop over itself

tools/nolibc: fix missing includes causing build issues at -O0

tools/nolibc/string: Fix memcmp() implementation

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

tools/nolibc/string: Implement `strdup()` and `strndup()`

tools/nolibc/string: Implement `strnlen()`

tools/nolibc/string: do not use __builtin_strlen() at -O0

tools/nolibc/string: add strcmp() and strncmp()

tools/nolibc/string: export memset() and memmove()

tools/nolibc: use standard asm statements