llvm dev - Feb 2017 - 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);
   #endif
 #endif

-#if defined(__linux__) && defined(__arm__)
-  #include <asm/unistd.h>
-#endif
-
 /*
  * The compiler generates calls to __clear_cache() when creating
  * trampoline functions on the stack for use with nested functions.
@@ -108,6 +104,7 @@ void __clear_cache(void *start, void *end) {

         sysarch(ARM_SYNC_ICACHE, &arg);
     #elif defined(__linux__)
+        #define __ARM_NR_cacheflush 0x0f0002
          register int start_reg __asm("r0") = (int) (intptr_t) start;
          const register int end_reg __asm("r1") = (int) (intptr_t)
end;
          const register int flags __asm("r2") = 0;


-------------- next part --------------
A non-text attachment was scrubbed...
Name: compiler-rt-remove-kernel-header.patch
Type: text/x-patch
Size: 842 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170126/a4564b7a/attachment.bin>

On 26 January 2017 at 10:57, Joakim Sindholt via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.
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
(arch/arm/include/uapi/asm/unistd.h).

Saleem, any objections?

cheers,
--renato

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.

On Sun, Feb 12, 2017 at 2:26 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 26 January 2017 at 10:57, Joakim Sindholt via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 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.
>
> 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
> (arch/arm/include/uapi/asm/unistd.h).
>
> Saleem, any objections?
>
> cheers,
> --renato
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170212/223891d3/attachment.html>