Re: [RFC PATCH v2 02/10] tools/nolibc: crt: Split _start_c() into stack-only and normal parts

[Willy Tarreau]

On Wed, Feb 04, 2026 at 09:45:34PM +0900, Daniel Palmer wrote:
> To prepare for nolibc programs being able to relocate themselves
> we need to split _start_c() into two parts:
> 
> - One part that only uses the stack so there are no accesses via
>   the GOT etc that isn't setup yet. Note that on m68k at least
>   this also means forcing the stackprotector off because accessing
>   the stack protector canary is done via the GOT.
> 
> - Another part that is called after we have done relocation so it
>   is safe to access global variables etc that might use the GOT etc.
> 
> Signed-off-by: Daniel Palmer <daniel@xxxxxxxxx>
> ---
>  tools/include/nolibc/compiler.h |  6 ++++
>  tools/include/nolibc/crt.h      | 57 ++++++++++++++++++---------------
>  2 files changed, 38 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/include/nolibc/compiler.h b/tools/include/nolibc/compiler.h
> index 87090bbc53e0..3f403e54e4f4 100644
> --- a/tools/include/nolibc/compiler.h
> +++ b/tools/include/nolibc/compiler.h
> @@ -47,4 +47,10 @@
>  #  define __nolibc_fallthrough do { } while (0)
>  #endif /* __nolibc_has_attribute(fallthrough) */
>  
> +#if __nolibc_has_feature(undefined_behavior_sanitizer)
> +#  define __no_sanitize __attribute__((no_sanitize("function")))
> +#else
> +#  define __no_sanitize
> +#endif

I'm starting to feel uncomfortable with the addition of new __no_foo
stuff, which doesn't have the "nolibc" prefix, risking to conflict with
userland code. I think we'll have to go through a cleanup patch at some
point for __no_sanitize and __no_stack_protector.

So probably in order to reduce the technical debt it would be nice to
to prepend __nolibc in front of this new internal macro. Maybe this part
of the patch should be a separate cleanup patch by the way, as future
patches might depend on it.

Willy