[patch] implement __clear_cache for arm32 & mips

[JF Bastien]

>
>
> * It would be better to put the ARM code with the NetBSD ARM code, not
>> separate.
>>
>
> I don't see how I can combine them, (since struct arm_sync_icache_args
> looks like
> it's BSD specific). I can move the two implementations together in the
> file, though.
>

Sorry, I meant next to each other, not merged.


>
>
>>  * Some platforms apparently fail doing this properly, and syscall
>> returns an error. I don't know if Android guarantees that this works, but
>> it may be worth checking the return value and aborting on syscall failure.
>>
>
> There's several critical codepaths on android that assume success. I don't
> see a
> CTS test that ensures that android kernels support it, though. I don't
> mind adding an
> abort, since it's pretty dangerous to assume that it will succeeds. What's
> the right
> "accepted" way to do that ? call compilerrt_abort() ?
>

I don't know compiler-rt well, but it looks right. For Android it'll call
abort, is that the right thing for you? Maybe the compilerrt_abort
implementation needs to also have an Android specialization?


>
>
>>  * JITs I've seen all use inline asm with a straight call to svc (with
>> proper ARM/Thumb headache). There seems to be mysticism around this that
>> I've never quite grasped, since the compiler should just emit the svc. See:
>> http://v8.googlecode.com/svn/branches/bleeding_edge/src/arm/cpu-arm.cc
>>
>
> I somewhat naively assumed that there would be code does this somewhere
> in the compiler-rt codebase, but there doesn't appear to be any.
>
> Is using the chromium code here an option ? Is the v8 / chromium license
> compatible with compiler-rt's ? Where does third party code go ?
>

I don't think copy/paste is the right thing, but calling svc is simple
enough that a different implementation (one for ARM and one for Thumb)
should work, in the same style as other inline asm in this file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140305/d59eeb2b/attachment.html>