On Wed, Aug 28, 2024 at 07:12:55PM +0200, Ard Biesheuvel wrote:
On Wed, 28 Aug 2024 at 18:24, Segher Boessenkool segher@kernel.crashing.org wrote:
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?
I think we agree? :-)
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 true. Yes, this cause problems for their users.
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.
Yeah. In many cases GCC will replace such calls by (faster and/or smaller) inline code anyway, but when it does leave a call, there needs to be an external function implementing it :-)
Not sure about static binaries, though: do those even use the VDSO?
With "static binary" people usually mean "a binary not using any DSOs", I think the VDSO is a DSO, also in this respect? As always, -static builds are *way* less problematic (and faster and smaller :-) )
Segher