On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> wrote: > > Hi! > > On Wed, Aug 28, 2024 at 05:40:23PM +0200, Ard Biesheuvel wrote: > > On Wed, 28 Aug 2024 at 14:57, Segher Boessenkool > > <segher@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Wed, Aug 28, 2024 at 12:24:12PM +0000, Arnd Bergmann wrote: > > > > On Wed, Aug 28, 2024, at 11:18, Jason A. Donenfeld wrote: > > > > > On Tue, Aug 27, 2024 at 05:53:30PM -0500, Segher Boessenkool wrote: > > > > >> On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote: > > > > >> > > > > > >> > 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? > That is exactly the point I am making. So how would this help in this case? > 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. > > > > (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. > Even if this were true, we support Clang versions today that do not support -fno-tree-loop-distribute-patterns so my point stands. > > 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 :-) > Good point. We should just import memcpy and memset in the VDSO ELF metadata. Not sure about static binaries, though: do those even use the VDSO?
