compiler-rt linux-arm builtins/clear_cache.c depends on kernel headers

builtins/clear_cache.c depends on kernel headers.

It's difficult to ascertain whether it's mixing with libc headers
but if it is then that's a bug in its own right.
Either way, it's pulling in kernel headers for a single #defined
constant that's been part of the linux ABI for years now. This
makes it more difficult to cross compile for, in my opinion, no
good reason. So here's a patch to just place the #define inline.

I'm not a member of the list so please CC me on replies.

diff --git a/lib/builtins/clear_cache.c b/lib/builtins/clear_cache.c
index 4c2ac3b..191598d 100644
--- a/lib/builtins/clear_cache.c
+++ b/lib/builtins/clear_cache.c
@@ -82,10 +82,6 @@ uintptr_t GetCurrentProcess(void);

-#if defined(__linux__) && defined(__arm__)
- #include <asm/unistd.h>

compiler-rt-remove-kernel-header.patch (842 Bytes)

Hi Joakim,

Sorry it took so long. I'm copying Saleem who knows more than I do about this.

That define seems harmless. I checked kernel 3.13 and current trunk
and the defines are the same. For compatibility, I seriously doubt
they're going to change it anytime soon.

I'd just add a comment where that line is from

Saleem, any objections?


Hmm, I dont think that this is terrible. However, since I dont belive that Linux guarantees the stability of its interfaces, I think that adding a trivial test for this would be waranteed.

I think Linux is pretty far towards the conservative end on changing
syscalls (via the "don't break user space" rule that Linus is keen
on). Windows & macOS, you're on your own.


Ok, I committed in r295738. Let's see if this causes any trouble, but
I'm not expecting any.

Thanks Joakim!