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

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

>From speaking to a few people internally and digging a bit further into the code it seems like:

- 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. 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 guess the question is whether failure of __builtin___clear_cache is sufficient to unconditionally terminate the program. 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