| 1c3a4c10 | 04-Mar-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: check for S_I* macros before defining them
Defining S_I* flags in types.h can cause some build failures if linux/stat.h is included prior to it. But if not defined, some toolchains tha
tools/nolibc: check for S_I* macros before defining them
Defining S_I* flags in types.h can cause some build failures if linux/stat.h is included prior to it. But if not defined, some toolchains that include some glibc parts will in turn fail because linux/stat.h already takes care of avoiding these definitions when glibc is present.
Let's preserve the macros here but first include linux/stat.h and check for their definition before doing so. We also define the previously missing permission macros so that we don't get a different behavior depending on the first include found.
Cc: Feiyang Chen <chenfeiyang@loongson.cn> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 919d0532 | 04-Mar-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: add getuid() and geteuid()
This can be useful to avoid attempting some privileged operations, starting from the nolibc-test tool that gets two failures when not privileged.
We call ge
tools/nolibc: add getuid() and geteuid()
This can be useful to avoid attempting some privileged operations, starting from the nolibc-test tool that gets two failures when not privileged.
We call getuid32() and geteuid32() when they are defined, and fall back to getuid() and geteuid() otherwise.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 3e9fd4e9 | 04-Mar-2023 |
Vincent Dagonneau <v@vda.io> |
tools/nolibc: add integer types and integer limit macros
This commit adds some of the missing integer types to stdint.h and adds limit macros (e.g. INTN_{MIN,MAX}).
The reference used for adding th
tools/nolibc: add integer types and integer limit macros
This commit adds some of the missing integer types to stdint.h and adds limit macros (e.g. INTN_{MIN,MAX}).
The reference used for adding these types is https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html.
We rely on the compiler-defined __LONG_MAX__ to get the right limits for size_t, intptr_t, uintptr_t and ptrdiff_t. This compiler constant seem to have been defined at least since GCC 4.1.2 and clang 3.0.0 on x86_64. It is also defined on ARM (32&64), mips and RISC-V.
Note that the maximum size of size_t is implementation-defined (>65535), in this case I chose to go with unsigned long on all platforms since unsigned long == unsigned int on all the platforms we care about. Note that the kernel uses either unsigned int or unsigned long in linux/include/uapi/asm-generic/posix_types.h. These should be equivalent for the plaforms we are targeting.
Also note that the 'fast*' flavor of the types have been chosen to be always 1 byte for '*fast8*' and always long (a.k.a. intptr_t/uintptr_t) for the other variants. I have never seen the 'fast*' types in use in the wild but that seems to be what glibc does.
Signed-off-by: Vincent Dagonneau <v@vda.io> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| c34da317 | 04-Mar-2023 |
Vincent Dagonneau <v@vda.io> |
tools/nolibc: add stdint.h
Nolibc works fine for small and limited program however most program expect integer types to be defined in stdint.h rather than std.h.
This is a quick fix that moves the
tools/nolibc: add stdint.h
Nolibc works fine for small and limited program however most program expect integer types to be defined in stdint.h rather than std.h.
This is a quick fix that moves the existing integer definitions in std.h to stdint.h.
Signed-off-by: Vincent Dagonneau <v@vda.io> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 7efd762e | 10-Jan-2023 |
Ammar Faizi <ammarfaizi2@gnuweeb.org> |
nolibc/sys: Implement `getpagesize(2)` function
This function returns the page size used by the running kernel. The page size value is taken from the auxiliary vector at 'AT_PAGESZ' key.
'getpagesi
nolibc/sys: Implement `getpagesize(2)` function
This function returns the page size used by the running kernel. The page size value is taken from the auxiliary vector at 'AT_PAGESZ' key.
'getpagesize(2)' is assumed as a syscall becuase the manpage placement of this function is in entry 2 ('man 2 getpagesize') despite there is no real 'getpagesize(2)' syscall in the Linux syscall table. Define this function in 'sys.h'.
Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| c61a0780 | 10-Jan-2023 |
Ammar Faizi <ammarfaizi2@gnuweeb.org> |
nolibc/stdlib: Implement `getauxval(3)` function
Previous commits save the address of the auxiliary vector into a global variable @_auxv. This commit creates a new function 'getauxval()' as a helper
nolibc/stdlib: Implement `getauxval(3)` function
Previous commits save the address of the auxiliary vector into a global variable @_auxv. This commit creates a new function 'getauxval()' as a helper function to get the auxv value based on the given key.
The behavior of this function is identic with the function documented in 'man 3 getauxval'. This function is also needed to implement 'getpagesize()' function that we will wire up in the next patches.
Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 241c4b4e | 10-Jan-2023 |
Sven Schnelle <svens@linux.ibm.com> |
tools/nolibc: add auxiliary vector retrieval for s390
In the _start block we now iterate over envp to find the auxiliary vector after the NULL. The pointer is saved into an _auxv variable that is ma
tools/nolibc: add auxiliary vector retrieval for s390
In the _start block we now iterate over envp to find the auxiliary vector after the NULL. The pointer is saved into an _auxv variable that is marked as weak so that it's accessible from multiple units.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 59ea1876 | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: add auxiliary vector retrieval for arm
In the _start block we now iterate over envp to find the auxiliary vector after the NULL. The pointer is saved into an _auxv variable that is mar
tools/nolibc: add auxiliary vector retrieval for arm
In the _start block we now iterate over envp to find the auxiliary vector after the NULL. The pointer is saved into an _auxv variable that is marked as weak so that it's accessible from multiple units.
Signed-off-by: Willy Tarreau <w@1wt.eu>
It was tested in arm, thumb1 and thumb2 modes.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 9e5bdc61 | 10-Jan-2023 |
Sven Schnelle <svens@linux.ibm.com> |
tools/nolibc: export environ as a weak symbol on s390
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it.
tools/nolibc: export environ as a weak symbol on s390
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested on s390 both with environ inherited from _start and extracted from envp.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 758f3337 | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: export environ as a weak symbol on riscv
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it.
tools/nolibc: export environ as a weak symbol on riscv
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested on riscv64 both with environ inherited from _start and extracted from envp.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 8f7fafeb | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: export environ as a weak symbol on mips
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it.
tools/nolibc: export environ as a weak symbol on mips
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested with mips24kc (BE) both with environ inherited from _start and extracted from envp.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| a6f29a2c | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: export environ as a weak symbol on arm
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. B
tools/nolibc: export environ as a weak symbol on arm
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested in arm and thumb1 and thumb2 modes, and for each mode, both with environ inherited from _start and extracted from envp.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 9b8688c6 | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: export environ as a weak symbol on arm64
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it.
tools/nolibc: export environ as a weak symbol on arm64
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested both with environ inherited from _start and extracted from envp.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 52e423f5 | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: export environ as a weak symbol on i386
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it.
tools/nolibc: export environ as a weak symbol on i386
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested both with environ inherited from _start and extracted from envp.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 89dc5092 | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: export environ as a weak symbol on x86_64
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it
tools/nolibc: export environ as a weak symbol on x86_64
The environ is retrieved from the _start code and is easy to store at this moment. Let's declare the variable weak and store the value into it. By not being static it will be visible to all units. By being weak, if some programs already declared it, they will continue to be able to use it. This was tested both with environ inherited from _start and extracted from envp.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 1caa1154 | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: make errno a weak symbol instead of a static one
Till now errno was declared static so that it could be eliminated if unused. While the goal is commendable for tiny executables as it a
tools/nolibc: make errno a weak symbol instead of a static one
Till now errno was declared static so that it could be eliminated if unused. While the goal is commendable for tiny executables as it allows to eliminate any data and bss segments when not used, this comes with some limitations, one of which being that the errno symbol seen in different units are not the same. Even though this has never been a real issue given the nature of the programs involved till now, it happens that referencing the same symbol from multiple units can also be achieved using weak symbols, with a difference being that only one of them will be used for all of them. Compared to weak symbols, static basically have no benefit for regular programs since there are always at least a few variables in most of these, so the bss segment cannot be eliminated. E.g:
$ size nolibc-test-static-errno text data bss dec hex filename 11531 0 48 11579 2d3b nolibc-test-static-errno
Furthermore, the weak symbol doesn't use bss storage at all, resulting in a slightly section:
$ size nolibc-test-weak-errno text data bss dec hex filename 11531 0 40 11571 2d33 nolibc-test-weak-errno
This patch thus converts errno from static to weak.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 5a51b6de | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: support thumb mode with frame pointers on ARM
In Thumb mode, register r7 is normally used to store the frame pointer. By default when optimizing at -Os there's no frame pointer so this
tools/nolibc: support thumb mode with frame pointers on ARM
In Thumb mode, register r7 is normally used to store the frame pointer. By default when optimizing at -Os there's no frame pointer so this works fine. But if no optimization is set, then build errors occur, indicating that r7 cannot not be used. It's difficult to cheat because it's the compiler that is complaining, not the assembler, so it's not even possible to report that the register was clobbered. The solution consists in saving and restoring r7 around the syscall, but this slightly inflates the code. The syscall number is passed via r6 which is never used by syscalls.
The current patch adds a few macroes which do that only in Thumb mode, and which continue to directly assign the syscall number to register r7 in ARM mode. Now this always builds and works for all modes (tested on Arm, Thumbv1, Thumbv2 modes, at -Os, -O0, -O0 -fomit-frame-pointer). The code is very slightly inflated in thumb-mode without frame-pointers compared to previously (e.g. 7928 vs 7864 bytes for nolibc-test) but at least it's always operational. And it's possible to disable this mechanism by setting NOLIBC_OMIT_FRAME_POINTER.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|
| 20470dfd | 10-Jan-2023 |
Willy Tarreau <w@1wt.eu> |
tools/nolibc: enable support for thumb1 mode for ARM
Passing -mthumb to the kernel.org arm toolchain failed to build because it defaults to armv5 hence thumb1, which has a fairly limited instruction
tools/nolibc: enable support for thumb1 mode for ARM
Passing -mthumb to the kernel.org arm toolchain failed to build because it defaults to armv5 hence thumb1, which has a fairly limited instruction set compared to thumb2 enabled with armv7 that is much more complete. It's not very difficult to adjust the instructions to also build on thumb1, it only adds a total of 3 instructions, so it's worth doing it at least to ease use by casual testers. It was verified that the adjusted code now builds and works fine for armv5, thumb1, armv7 and thumb2, as long as frame pointers are not used.
Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
show more ...
|