[PATCH] D60719: Demonstrate how to fix freestanding for memcpy
Tim Northover via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 17 11:42:25 PDT 2019
t.p.northover added a comment.
> IIUC freestanding environment should not rely on memcpy being present so my take on it was that by "fixing" freestanding I could have my cake and eat it too.
The formal situation is that freestanding implementations are only required to provide language support stuff like `va_list`. They're allowed to give more of the standard library if they want though, as implementation defined behaviour.
In practice, everyone I know provides the basic `string.h` functions and the compiler is pretty explicit about relying on them being present for correctness. They're part of the surrounding environment a user is expected to supply (much like the various exception handling callbacks if you want C++ exceptions, but always required).
For the people actually using freestanding I think they're mostly considered important enough that they're implemented in assembly anyway so this isn't really a burden, but...
> Ultimately I'm interested in implementing libc's mem function in C++. Let's take memcpy for instance
Ah, that is an entirely different problem from what I thought you were trying to do. In that case I'm all in favour of some solution, but would start thinking along the lines of `-fno-builtin-memcpy` options (it's possible that already does what you want, but can't get LLVM to form a `memcpy` from quick tests to check).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60719/new/
https://reviews.llvm.org/D60719
More information about the llvm-commits
mailing list