search for: __aeabi

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

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 > StatSymbols hack. > Hi James, I may be wrong, but I remember LLVM treating "androideabi" as "aeabi", which is wrong. This ma...

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 JITMemoryManager.cpp since it's required for both the JIT and MCJIT...

Hi, all I used Clang to compile an ARM-v6m project. The runtime library is from GNU-ARM. But as I used 'memcpy' function, an error 'undefined reference to `__aeabi_memcpy' was emitted by linker. Does it mean that I must use LLVM compiler-RT instead? Thanks a lot. -------------- Steven ***************************** Legal Disclaimer ***************************** "This email may contain confidential and privileged material for the sole use of the inte...

...to:llvmdev-bounces at cs.uiuc.edu] On Behalf Of James Lyon Sent: Sunday, November 10, 2013 5:45 PM To: LLVM Dev Subject: [LLVMdev] Android JIT patch 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 JITMemoryManager.cpp since it's required for both the JIT and MCJIT, a...

....edu] On Behalf Of James Lyon > Sent: Sunday, November 10, 2013 5:45 PM > To: LLVM Dev > Subject: [LLVMdev] Android JIT patch > > 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 JITMemoryManager.cpp since it's required for both the JIT and...

...> On Behalf Of James Lyon > Sent: Sunday, November 10, 2013 5:45 PM > To: LLVM Dev > Subject: [LLVMdev] Android JIT patch > > 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 JITMemoryManager.cpp since it's required for both the JIT and...

...Lyon >> Sent: Sunday, November 10, 2013 5:45 PM >> To: LLVM Dev >> Subject: [LLVMdev] Android JIT patch >> >> 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 JITMemoryManager.cpp since it's required for both the...

...ich is quite ugly. >> >> What do you think of this? >> >> #define EXPOSE_STATIC_FUNCTION (fn) if (Name == #fn) return >> (uint64_t)&fn; >> >> And then inside getSymbolAddress: >> >> #if ... conditions ... >> EXPOSE_STATIC_FUNCTION(__aeabi_d2f); >> EXPOSE_STATIC_FUNCTION(__aeabi_d2iz); >> EXPOSE_STATIC_FUNCTION(__aeabi_d2lz); >> etc. >> #endif >> >> -Andy >> >> -----Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent: Thursday, Nove...

...;) return (uint64_t)&foo;' pattern, which is quite ugly. > > What do you think of this? > > #define EXPOSE_STATIC_FUNCTION (fn) if (Name == #fn) return (uint64_t)&fn; > > And then inside getSymbolAddress: > > #if ... conditions ... > EXPOSE_STATIC_FUNCTION(__aeabi_d2f); > EXPOSE_STATIC_FUNCTION(__aeabi_d2iz); > EXPOSE_STATIC_FUNCTION(__aeabi_d2lz); > etc. > #endif > > -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Thursday, November 14, 2013 1:25 PM > To: Kaylor, Andr...

...rapped the 'if (Name == "foo") return (uint64_t)&foo;' pattern, which is quite ugly. What do you think of this? #define EXPOSE_STATIC_FUNCTION (fn) if (Name == #fn) return (uint64_t)&fn; And then inside getSymbolAddress: #if ... conditions ... EXPOSE_STATIC_FUNCTION(__aeabi_d2f); EXPOSE_STATIC_FUNCTION(__aeabi_d2iz); EXPOSE_STATIC_FUNCTION(__aeabi_d2lz); etc. #endif -Andy -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Thursday, November 14, 2013 1:25 PM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch...

...urn (uint64_t)&foo;' pattern, which is quite ugly. > > What do you think of this? > > #define EXPOSE_STATIC_FUNCTION (fn) if (Name == #fn) return > (uint64_t)&fn; > > And then inside getSymbolAddress: > > #if ... conditions ... > EXPOSE_STATIC_FUNCTION(__aeabi_d2f); > EXPOSE_STATIC_FUNCTION(__aeabi_d2iz); > EXPOSE_STATIC_FUNCTION(__aeabi_d2lz); > etc. > #endif > > -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Thursday, November 14, 2013 1:25 PM > To: Kaylor, Andr...

...ch is quite ugly. >> >> What do you think of this? >> >> #define EXPOSE_STATIC_FUNCTION (fn) if (Name == #fn) return >> (uint64_t)&fn; >> >> And then inside getSymbolAddress: >> >> #if ... conditions ... >> EXPOSE_STATIC_FUNCTION(__aeabi_d2f); >> EXPOSE_STATIC_FUNCTION(__aeabi_d2iz); >> EXPOSE_STATIC_FUNCTION(__aeabi_d2lz); >> etc. >> #endif >> >> -Andy >> >> -----Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent: Thursday, Nove...