On Tue, Aug 18, 2020 at 3:25 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > Another thing that needs to be fixed is that at least lib/string.c needs > to be compiled with -ffreestanding. > > gcc-10 optimizes the generic memset implementation in there into a call > to memset. Now that's on x86 which doesn't use the generic > implementation, but this is just waiting to bite us. > > https://godbolt.org/z/6EhG15 I'll let you send the patch for that this time. (It's too bad godbolt doesn't have newer versions of GCC for cross compilation...cant test aarch64 gcc-10, for example.) It would be interesting for sure to see resulting differences in disassembly observed in lib/string.o with -ffreestanding. But, oof, that's not good. Certainly impressive and powerful loop idiom recognition, but wouldn't you consider it a bug that this optimization should probably first check that it's not replacing part of a loop with a potentially recursive call to itself? Admittedly, we've had the same shenanigans with memcpy implemented in terms of calls to __builtin_memcpy being lowered to infinitely recursive calls...which feels like the same kind of bug. ("You wanted infinite recursion in the kexec purgatory image, right?" "No, compiler, I did not.") example: https://godbolt.org/z/MzrTaM (probably should fix this in both implementations; at the least I feel like Clang's -Winfinite-recursion should try to help us out here). Feels almost like it may be difficult to provide an implementation of memset without stepping on a landmine. One thing I'd be curious about is whether all of lib/string.c would need -ffreestanding, or if you could move just memset to its own TU then use -ffreestanding on that. A free standing environment must always provide a core set of functions like memset, memcpy, memcmp, memmove, according to https://gcc.gnu.org/onlinedocs/gcc/Standards.html. Maybe those four should be in a separate TU compiled as -ffreestanding, so that they can never be lowered to calls to themselves (potentially infinitely recursive)? -- Thanks, ~Nick Desaulniers
