[PATCH] D37788: [ARM] builtins: Do not abort in clear_cache.

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 13 12:01:48 PDT 2017


rengolin added a comment.

In https://reviews.llvm.org/D37788#869943, @peter.smith wrote:

> - The prototype for the builtin is void __builtin___clear_cache (char *begin, char *end) so there isn't a way of reporting failure from that function to the caller
> - The system call can fail on Linux when StartAddress > EndAddress which the user can check themselves before calling, or if the access_ok check fails (see comment later) or if a data abort exception occurs when doing one of the CP15 cache manipulation instructions. According to the linux kernel code, this happens when the virtual address isn't mapped. So it looks like a program has given __builtin___clear_cache an invalid memory range.


Would be interesting to know how often these things happen in non-exceptional cases.

> In an ideal world __builtin___clear_cache would pass the error code up to the caller so that they could decide what to do about it, unfortunately it is a void function so we can't do that.

I'm coming at this frmo a pragmatic point of view, so we can ignore the ideal world scenario. :)

> There are defensible arguments on both sides, I'm tending towards the libgcc behaviour as that is what many applications will be expecting, if the error checking is needed then the OS specific functions could be used. In fact this may be the reason that the builtin doesn't return an error code as it has to be portable across many architectures and not all of these will have a cache clear that can fault.
> 
> access_ok for Arm expands to the __range_ok, the AArch64 has a comment that I've adapted for Arm.
> 
>   /*
>    * Test whether a block of memory is a valid user space address.
>    * Returns 1 if the range is valid, 0 otherwise.
>    *
>    * This is equivalent to the following test:
>    * (u33)addr + (u33)size <= current->addr_limit




https://reviews.llvm.org/D37788





More information about the llvm-commits mailing list