Re: [PATCH 3/6] linux: Implement mremap in C

[Xi Ruoyao <xry111@xry111.site>]

On Thu, 2024-06-06 at 17:26 -0300, Adhemerval Zanella Netto wrote:
> I don't really recall to be honest.  And I don't have a strong opinion, 
> the main issue is I would like to eventually get rid of the assembly
> hooks for the syscall auto-generation so we only have have it to support
> for generate it through C.  Besides the code simplification it has the
> side effect of playing better the LTO (which we still do not fully support,
> but maybe in the future).
> 
> I had a prototype for this, which also is slight faster since it generates
> the files in a bulk.

But GCC is generating some really stupid code for va_list.  I made
https://sourceware.org/pipermail/libc-alpha/2023-March/146624.html to
"work it around" but the patch was NAK'ed for some good reason (not to
invoke UB).

With a simple example:

#include <stdarg.h>

int func(int flag, int arg, ... /*int optional*/)
{
	if (!flag)
		return arg | 42;
	else {
		va_list ap;
		va_start(ap, arg);
		arg |= va_arg(ap, int);
		va_end(ap);
	}

	return arg;
}

int func_ub(int flag, int arg, int optional)
{
	if (!flag)
		return arg | 42;
	else
		return arg | optional;
}

we can demonstrate how the code generation for func is much worse than
func_ub.  Clang produces even more stupid code.

I hope someone can work on improving the compilers if we must use
va_list more and more...

> Besides the code simplification it has the side effect of playing
> better the LTO (which we still do not fully support, but maybe in the
> future).

Note that with LTO invoking UB deliberately won't be an option at all
(it is an option w/o LTO but already a really bad option).  So we need
some support from the compiler or we'll have to eat the stupid code from
va_list.

BTW has someone built Glibc with LTO?  I tried it and it never worked.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University