[LLVMdev] Android JIT patch

James Lyon jameslyon0 at gmail.com
Mon Nov 11 04:03:38 PST 2013


I think __aeabi is ARM EABI not Android EABI, e.g. 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0043d/index.html. 
The problem is not that the __aeabi functions are missing on Android, 
they're defined in libgcc.a, the problem is that they don't get linked 
in unless they're referenced. I don't know how this problem is avoided 
on ARM/Linux/glibc normally, but something pulls them in there according 
to my testing.

The way to avoid disabling setLastModificationAndAccessTime is to 
rewrite it to take a path and use utime/utimes instead (incidentally the 
setLastModificationAndAccessTime function is only used by llvm-ar). I 
don't know why it was written the way it is now; i.e. I'm not sure what 
systems have futimens but not futimes and vice-verse. I would guess that 
the utime function should be universal though. There's a HAVE_UTIME_H 
test in Config.h but it doesn't seem to be used anywhere.

James

On 11/11/13 08:30, Renato Golin wrote:
> On 11 November 2013 01:45, James Lyon <jameslyon0 at gmail.com 
> <mailto:jameslyon0 at gmail.com>> wrote:
>
>     I've attached a patch which has got JIT compilation working (for
>     me at least!) on Android. It turns out that the problem was a
>     bunch of intrinsic __aeabi* functions which reside in libgcc.a
>     rather than libc.so so are not available unless explicitly linked
>     in, so it's rather similar to the StatSymbols hack.
>
>
> Hi James,
>
> I may be wrong, but I remember LLVM treating "androideabi" as "aeabi", 
> which is wrong. This may be the source of your problem, and I think we 
> should teach Clang/LLVM to understand the Android ABI in its full form.
>
>
>     There's one other minor change since
>     setLastModificationAndAccessTime can't be supported on Android;
>     all relevant system calls are missing from the C library. I've
>     therefore changed the code to fail at runtime rather than
>     compile-time here.
>
>
> This sounds worse... I'd rather we fixed the behaviour than the cause...
>
> cheers,
> --renato

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131111/30415fc4/attachment.html>


More information about the llvm-dev mailing list