| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The logic to disable UBSAN will become a bit more complicated.
Move it out into compiler.h, so crt.h stays readable.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20260408-nolibc-gcc-15-v1-1-330d0c40f894@weissschuh.net
|
|
Add support for the GNU extensions 'program_invocation_name' and
'program_invocation_short_name'. These are useful to print error
messages, which by convention include the program name.
As these are global variables which take up memory even if not used,
similar to 'errno', gate them behind NOLIBC_IGNORE_ERRNO.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260318-nolibc-err-h-v4-1-08247a694bd9@weissschuh.net
|
|
In principle, it is possible to use nolibc for only some object files in
a program. In that case, the startup code in _start and _start_c is not
going to be used. Add the NOLIBC_NO_RUNTIME compile time option to
disable it entirely and also remove anything that depends on it.
Doing this avoids warnings from modpost for UML as the _start_c code
references the main function from the .init.text section while it is not
inside .init itself.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
|
|
Both constructors and main() may be executed with different function
signatures than they are actually using.
This is intentional but trips up UBSAN.
Disable the function sanitizer of UBSAN in _start_c().
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/r/20250419-nolibc-ubsan-v2-3-060b8a016917@weissschuh.net
|
|
With -Wmissing-prototypes the compiler will warn about non-static
functions which don't have a prototype defined.
This warning doesn't make much sense for nolibc itself but for user code
it is still useful.
To pacify the compiler add prototypes next to the function definitions,
similar to how it is handled elsewhere in the kernel.
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/r/20250123-nolibc-prototype-v1-1-e1afc5c1999a@weissschuh.net
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
|
|
During LTO the reference from the asm startup code to the _start_c()
function is not visible and _start_c() is removed.
This will then lead to errors during linking.
As _start_c() is indeed always used, mark it as such.
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/r/20240812-nolibc-lto-v2-1-736af7bbefa8@weissschuh.net
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
|
|
Since 2005 glibc has passed argc, argv, and envp to all constructors.
As it is cheap and easy to do so, mirror that behaviour in nolibc.
This makes it easier to migrate applications to nolibc.
Link: https://lore.kernel.org/r/20240728-nolibc-constructor-args-v1-1-36d0bf5cd4c0@weissschuh.net
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
|
|
With the startup code moved to C, implementing support for
constructors and deconstructors is fairly easy to implement.
Examples for code size impact:
text data bss dec hex filename
21837 104 88 22029 560d nolibc-test.before
22135 120 88 22343 5747 nolibc-test.after
21970 104 88 22162 5692 nolibc-test.after-only-crt.h-changes
The sections are defined by [0].
[0] https://refspecs.linuxfoundation.org/elf/gabi4+/ch5.dynamic.html
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/lkml/20231007-nolibc-constructors-v2-1-ef84693efbc1@weissschuh.net/
|
|
Otherwise the different instances of _start_c from each compilation unit
will lead to linker errors:
/usr/bin/ld: /tmp/ccSNvRqs.o: in function `_start_c':
nolibc-test-foo.c:(.text.nolibc_memset+0x9): multiple definition of `_start_c'; /tmp/ccG25101.o:nolibc-test.c:(.text+0x1ea3): first defined here
Fixes: 17336755150b ("tools/nolibc: add new crt.h with _start_c")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/lkml/20231012-nolibc-start_c-multiple-v1-1-fbfc73e0283f@weissschuh.net/
Link: https://lore.kernel.org/lkml/20231012-nolibc-linkage-test-v1-1-315e682768b4@weissschuh.net/
Acked-by: Willy Tarreau <w@1wt.eu>
|
|
This allows to generate smaller text/data/dec size.
As the _start_c() function added by crt.h, __stack_chk_init() is called
from _start_c() instead of the assembly _start. So, it is able to mark
it with static now.
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
|
|
As suggested by Thomas, It is able to move the stackprotector
initialization from the assembly _start to the beginning of the new
_start_c(). Let's call __stack_chk_init() in _start_c() as a
preparation.
Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/lkml/a00284a6-54b1-498c-92aa-44997fa78403@t-8ch.de/
Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
|
|
As the environ and _auxv support added for nolibc, the assembly _start
function becomes more and more complex and therefore makes the porting
of nolibc to new architectures harder and harder.
To simplify portability, this C version of _start_c() is added to do
most of the assembly start operations in C, which reduces the complexity
a lot and will eventually simplify the porting of nolibc to the new
architectures.
The new _start_c() only requires a stack pointer argument, it will find
argc, argv, envp/environ and _auxv for us, and then call main(),
finally, it exit() with main's return status. With this new _start_c(),
the future new architectures only require to add very few assembly
instructions.
As suggested by Thomas, users may use a different signature of main
(e.g. void main(void)), a _nolibc_main alias is added for main to
silence the warning about potential conflicting types.
As suggested by Willy, the code is carefully polished for both smaller
size and better readability with local variables and the right types.
Suggested-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/lkml/20230715095729.GC24086@1wt.eu/
Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/lkml/90fdd255-32f4-4caf-90ff-06456b53dac3@t-8ch.de/
Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
|
