Re: False positives in nolibc check

[Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>]

Hello Stefan,

On Tue, Jun 20, 2023 at 8:32 PM Stefan Hajnoczi wrote:
> This is caused by the stack protector compiler options, which depend on
> the libc __stack_chk_fail_local symbol.

liburing itself explicitly disables the stack protector, even when
compiled with libc. You customize the build and use something that
needs libc (stack protector). So I would say liburing upstream has
taken care of this problem in the normal build.

> The compile_prog check in ./configure should use the final
> CFLAGS/LDFLAGS (including -ffreestanding) that liburing is compiled with
> to avoid false positives. That way it can detect that nolibc won't work
> with these compiler options and fall back to using libc.
>
> In general, I'm concerned that nolibc is fragile because the toolchain
> and libc sometimes have dependencies that are activated by certain
> compiler options. Some users will want libc and others will not. Maybe
> make it an explicit option instead of probing?

I'm not sure it's worth using libc in liburing (x86(-64) and aarch64)
just to activate the stack protector. Do you have other convincing use
cases where libc is strictly needed on architectures that support
liburing nolibc?

I think using stack protector for liburing is just too overkill, but I
may be wrong, please tell me a good reason for using it in liburing.

I admit that nolibc brings problems. For example, the memset() issue
on aarch64 recently (it's fixed). If you have similar problems, please
tell. We probably should consider bringing back the "--nolibc" option
in the "./configure" file?

> I've included a downstream patch in the Fedora package that disables
> nolibc for the time being.

Thanks for maintaining the package. I appreciate it.

-- Viro