similar to: [LLVMdev] Android build patch

The CMake changes look fine to me, landed in r194051! As for the JITMemoryManager.cpp changes, not so sure. Did you try disabling the 'hack' described below instead of patching it? | ||//===----------------------------------------------------------------------===//|| ||// Function stubs that are invoked instead of certain library calls|| ||//|| ||// Force the following functions to be

I suppose I was just doing the "smallest" thing. Disabling the hack entirely also allows it to build and is probably the correct thing to do. I'm not that knowledgeable about glibc vs. Bionic differences so the thing to do would be to test whether those functions work without the "hack" on Android. Unfortunately at the moment I can't get my Android JIT test program

Hmmm.... following up on your point I've noticed something strange. futimens is missing from the NDK (r9b; it's not in any headers and the libc.so files are the same all the way back to android-9), which is why I thought it's missing from Android generally. The NDK is by far the easiest way to cross-compile since it provides a standalone cross-compilation toolchain. It is however

On 25/11/2013 18:27, Stephen Hines wrote: > futimens() is available in Android KitKat. We work extensively with > LLVM and this allowed us to remove our ugly workaround for not having > this functionality. Hi Steve, Is your work on a branch somewhere? James is putting a lot of time into this, and the LLVM community has been making best efforts to help review his patches which can be

This is only available for apps that target API level 19 and up. On 18 and lower, the futimens() function won't be available via libc.so. You will need to target API 19 (KitKat) in order to actually use it. If I do an "nm -D prebuilts/ndk/9/platforms/android-19/arch-arm/usr/lib/libc.so", I can see futimens() is present. On the others, it is definitely missing. Steve On Mon, Nov

On Mon, Nov 25, 2013 at 12:36 PM, Alp Toker <alp at nuanti.com> wrote: > > On 25/11/2013 18:27, Stephen Hines wrote: > >> futimens() is available in Android KitKat. We work extensively with LLVM >> and this allowed us to remove our ugly workaround for not having this >> functionality. >> > > Hi Steve, > > Is your work on a branch somewhere? >

I'm trying to build LLVM on Android rather than the other way around! Really just to see if it can be done. I worked out the first problem (my code was written for the old JIT and I'd missed something in updating to the MCJIT to make it work on ARM). It still doesn't work, but at this point I have no idea why and it'll be a while before I get to look at it again: the Android

On 4 November 2013 23:45, James Lyon <jameslyon0 at gmail.com> wrote: > I'm trying to build LLVM on Android rather than the other way around! > Really just to see if it can be done. I worked out the first problem (my > code was written for the old JIT and I'd missed something in updating to > the MCJIT to make it work on ARM). It still doesn't work, but at this

On 30 October 2013 17:08, James Lyon <jameslyon0 at gmail.com> wrote: > Sadly even though it builds I can't get generated code to work - it > appears at the moment that the generated code doesn't have execute > permissions set for some reason (this is 3.3, not svn). Hi, You may have a look at the LLVM Linux builds ( http://llvm.linuxfoundation.org/index.php/Main_Page),

futimens() is available in Android KitKat. We work extensively with LLVM and this allowed us to remove our ugly workaround for not having this functionality. Steve On Mon, Nov 25, 2013 at 8:30 AM, James Lyon <jameslyon0 at gmail.com> wrote: > Hi, > > I've been trying to get LLVM working as a JIT compiler on Android for a > while. It works now, except that the

Hi, I've been trying to get LLVM working as a JIT compiler on Android for a while. It works now, except that the setLastModificationAndAccessTime function won't build because the Bionic C library lacks both futimes and futimens. There doesn't appear to be any "nice" workaround for this problem: the only ways I can think of to make setLastModificationAndAccessTime work

This is getting a bit off-topic, but since Renato brought up RenderScript, I wonder if the Android libbcc interface wouldn't be a cleaner way to approach this problem. It provides more or less the same functionality as MCJIT and in almost the same way. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Renato Golin Sent: Tuesday, November 05,

Is it possible to try your program on a non-Android Linux? It might make debugging a bit less painful. If you haven't updated to the trunk code recently, it's possible that calling finalizeObject more than once would cause a crash. The changes that introduced multiple module support should have fixed that issue. It might be useful to set breakpoints in the memory manager you are using.

Here's an updated version with more comments. James On 14/11/13 23:06, Kaylor, Andrew wrote: > Oh, I see now. It turns out that even knowing what the end goal was I misunderstood part of what the macros were doing. > > If you could add some comments explaining what the macros are doing then I guess I can live with the patch in this form. I definitely agree that it's better not

On 11 November 2013 01:45, James Lyon <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 >

Committed as r194832. -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Thursday, November 14, 2013 4:58 PM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch Here's an updated version with more comments. James On 14/11/13 23:06, Kaylor, Andrew wrote: > Oh, I see now. It turns out that even knowing what the end goal was I

Well, the reason I did it that way was that the list of functions is fairly long and has to be written out twice; once to declare the functions and once to do the if(Name==#fn) bit, and I thought nested macros was simpler than having two copies of the list. On 14/11/13 22:07, Kaylor, Andrew wrote: > Thanks for splitting up the patch. I'm not the right person to comment on the

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. I moved the StatSymbols code into ExecutionEngine.cpp rather than

Oh, I see now. It turns out that even knowing what the end goal was I misunderstood part of what the macros were doing. If you could add some comments explaining what the macros are doing then I guess I can live with the patch in this form. I definitely agree that it's better not to have two copies of the list. Thanks, Andy -----Original Message----- From: James Lyon [mailto:jameslyon0

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