Hi!

On Wed, Aug 28, 2024 at 05:40:23PM +0200, Ard Biesheuvel wrote:

On Wed, 28 Aug 2024 at 14:57, Segher Boessenkool
[off-list ref] wrote:

quoted

On Wed, Aug 28, 2024 at 12:24:12PM +0000, Arnd Bergmann wrote:

quoted

On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote:

quoted

On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote:

quoted

On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:

quoted

Is there a compiler flag that could be used to disable the generation of calls
to memset?

-fno-tree-loop-distribute-patterns .  But, as always, read up on it, see
what it actually does (and how it avoids your problem, and mostly: learn
what the actual problem *was*!)

This might help with various loops, but it doesn't help with the matter
that this patch fixes, which is struct initialization. I just tried it
with the arm64 patch to no avail.

Maybe -ffreestanding can help here? That should cause the vdso to be built
with the assumption that there is no libc, so it would neither add nor
remove standard library calls. Not sure if that causes other problems,
e.g. if the calling conventions are different.

"GCC requires the freestanding
environment provide 'memcpy', 'memmove', 'memset' and 'memcmp'."

This is precisely to implement things like struct initialisation.  Maybe
we should have a "-ffreeerstanding" or "-ffreefloating" or think of
something funnier still environment as well, this problem has been there
since the -ffreestanding flag has existed, but the problem is as old as
the night.

-fno-builtin might help a bit more, but just attack the problem at
its root, like I suggested?

In my experience, this is likely to do the opposite: it causes the
compiler to 'forget' the semantics of memcpy() and memset(), so that
explicit trivial calls will no longer be elided and replaced with
plain loads and stores (as it can no longer guarantee the equivalence)

No, the compiler will never forget those semantics.  But if you tell it
your function named memset() is not the actual standard memset -- via
-fno-builtin-memset for example -- the compiler won't optimise things
involving it quite as much.  You told it so eh?

You can also tell it not to have a __builtin_memset function, but in
this particular case that won;t quite work, since the compiler does need
to have that builtin available to do struct and array initialisations
and the like.

quoted

(This isn't a new problem, originally it showed up as "GCC replaces
(part of) my memcpy() implementation by a (recursive) call to memcpy()"
and, well, that doesn't quite work!)

This needs to be fixed for Clang as well, so throwing GCC specific
flags at it will at best be a partial solution.

clang says it is a 100% plug-in replacement for GCC, so they will have
to accept all GCC flags.  And in many cases they do.  Cases where they
don't are bugs.

It is not a complete solution, unfortunately, and I guess there may be
other situations (compiler/arch combinations) where this might pop up
again.

Why do mem* not work in VDSOs?  Fix that, and all these problems
disappear, and you do not need workrarounds :-)


Segher