similar to: [LLVMdev] Android, llvm-ar and setLastModificationAndAccessTime

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

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

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

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 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

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 >

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

Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The

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

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

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

Thanks for splitting up the patch. I'm not the right person to comment on the modification and access time changes (though it looks alright to me). You might want to re-submit that part on its own as it's likely to be ignored by people who aren't interested in JIT stuff otherwise. Regarding the memory manager changes, functionally this looks good. I'm not a big fan of macros,

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

The various ExecutionEngine pieces may be the only places within LLVM that are using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. Is

On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of problems with this patch. > > First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. The direction of LLVM is not something I'm in a position to

On Jun 24, 2013, at 4:18 PM, Stefan Teleman <stefan.teleman at gmail.com> wrote: > I'll file the bug about the endian stuff, but we'll also have to have > an <endian.h> in Solaris as well. Do you still have issues after r182419? commit 01ef4f6982451e6a7c00a713d9ae677d3a15d042 Author: Jakob Stoklund Olesen <stoklund at 2pi.dk> Date: Tue May 21 13:36:13 2013

On Mon, Jun 24, 2013 at 6:17 PM, Jorge Rodrigues <skeept at gmail.com> wrote: > Norm, > > thanks for the help. Applying the fix solves the issue I mentioned but now I > have more issues. > > I can install clang, but when running I cannot compile and link files. > If I compile with -c flag it works but compiling the following x.c file > gives an error: >

On Tue, Dec 6, 2011 at 2:11 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sun, Dec 4, 2011 at 9:06 AM, Manuel Klimek <klimek at google.com> wrote: >> On Sat, Dec 3, 2011 at 10:33 PM, Douglas Gregor <dgregor at apple.com> wrote: >>> Hi Manuel, >>> >>> On Nov 28, 2011, at 2:49 AM, Manuel Klimek wrote: >>> >>>>

On Tue, Dec 6, 2011 at 2:27 AM, Manuel Klimek <klimek at google.com> wrote: > On Tue, Dec 6, 2011 at 2:11 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> On Sun, Dec 4, 2011 at 9:06 AM, Manuel Klimek <klimek at google.com> wrote: >>> On Sat, Dec 3, 2011 at 10:33 PM, Douglas Gregor <dgregor at apple.com> wrote: >>>> Hi Manuel,