Displaying 20 results from an estimated 40 matches for "addsymbols".
Did you mean:
addsymbol
2013 Nov 11
0
[LLVMdev] Android JIT patch
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.
Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the
2013 Nov 11
2
[LLVMdev] Android JIT patch
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
2013 Nov 11
4
[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
2010 Aug 19
2
[LLVMdev] using external functions from llvm
Is there documentation somewhere on how to call external functions from
llvm? The only guide I found was this: http://www.gearleaf.com/blog/post/44,
and it doesn't seem to be working for me.
I have a function:
llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const
std::vector<llvm::GenericValue>& args)
{
llvm_object_structure* result = new
2013 Nov 11
0
[LLVMdev] Android JIT patch
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
2013 Nov 14
3
[LLVMdev] Android JIT patch
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
2014 May 28
2
[LLVMdev] how to call the function in hosting code from JITted IR code..?
Dears,
I'm trying to call the function that defined in the host application from
IR code, but LLVM is saying that there is no such function...
I've seen the tutorial of Kaleidoscope, and defined the function as
extern "C" {
void test1(void) {
cout << "test function in the host application \n" ;
}
}
...in the host application.
Would you please let me give any
2015 Jan 05
2
[LLVMdev] LLVM linkage error - Program used external function 'foo' which could not be resolved!
Hi, All
I got a linkage error as indicated in the subject line. Any suggestion?
I created a call builder.CreateCall2(foo, p1, p2) in a module. foo is
a Function* generated by module->getOrInsertFunction("foo",
prototype). foo is defined outside of this module, and in the dump of
the module, I see "declare i64 @foo(xxx, xxx)". The error happens
during link time, it seems
2010 Aug 19
3
[LLVMdev] using external functions from llvm
The blog post I linked to implied that adding a symbol in the form
lle_X_FUNCTIONNAME would allow you to call a function called FUNCTIONNAME.
Is this not the case?
On Thu, Aug 19, 2010 at 6:46 PM, <o.j.sivart at gmail.com> wrote:
> You are adding the symbol as "lle_X_create_number_object" yet your error
> message implies you have tried to lookup and use
2010 Aug 19
0
[LLVMdev] using external functions from llvm
You are adding the symbol as "lle_X_create_number_object" yet your error message implies you have tried to lookup and use "create_number_object". Can you provide the code for the lookup?
On 20/08/2010, at 8:07 AM, Alec Benzer wrote:
> Is there documentation somewhere on how to call external functions from llvm? The only guide I found was this:
2013 Nov 15
3
[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 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
2013 Nov 14
2
[LLVMdev] Android JIT patch
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
2015 Mar 20
2
[LLVMdev] LLVM Exception Handling
Hi,
I am trying to implement a scenario similar to running ExceptionDemo.cpp
with parameter -1 (where the JITed code calls the C++ function which throws
an exception)
Different from the given example I am using IRParser instead of IRBuilder.
I can successfully catch the exception in Linux but the program crashes in
Mac and Windows.
The code is similar to as follows:
### The test.cpp :
2013 Nov 14
0
[LLVMdev] Android JIT patch
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,
2018 Apr 26
3
[lld] - LLD (ELF) code covered by test cases.
...low in ICF.cpp and all our tests pass.
(https://github.com/llvm-mirror/lld/blob/master/ELF/ICF.cpp#L386)
2) In Relocations.cpp, all code inside `if`:
https://github.com/llvm-mirror/lld/blob/master/ELF/Relocations.cpp#L1177
Is not covered by tests.
3) MicroMipsR6Thunk::writeTo(), MicroMipsR6Thunk::addSymbols(),
MicroMipsR6Thunk::getTargetInputSection() are not covered.
That seems to be all major places I saw in report.
Now we probably can think about what we can do with that?
* Ideal scenario I can imagine is that we could fix all the places and, for example, setup the watching bot
looking for LLD co...
2014 Mar 01
2
[LLVMdev] MCJIT crash on 64 bit Linux, works find on OSX
Hi All.
I have an issue when a MCJIT ExecutionEngine is created then deleted, any C++ exception thrown after the MCJIT dtor is called will result in a seg fault. This does not occur with the regular JIT engine, and only occurs on Linux, works fine on OSX.
basically its like this:
ExecutionEngine *e = engineBuilder.create();
// this is fine
try { throw exception()} catch(exception&) {}
2013 Nov 14
0
[LLVMdev] Android JIT patch
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
2013 Nov 15
0
[LLVMdev] Android JIT patch
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
2018 Apr 26
0
[lld] - LLD (ELF) code covered by test cases.
...pass.
> (https://github.com/llvm-mirror/lld/blob/master/ELF/ICF.cpp#L386)
>
> 2) In Relocations.cpp, all code inside `if`:
> https://github.com/llvm-mirror/lld/blob/master/ELF/Relocations.cpp#L1177
> Is not covered by tests.
>
> 3) MicroMipsR6Thunk::writeTo(), MicroMipsR6Thunk::addSymbols(),
> MicroMipsR6Thunk::getTargetInputSection() are not covered.
>
> That seems to be all major places I saw in report.
>
> Now we probably can think about what we can do with that?
> * Ideal scenario I can imagine is that we could fix all the places and, for example, setup the wat...
2013 Nov 01
0
[LLVMdev] [Proposal] Adding callback mechanism to Execution Engines
Unless I'm missing something, indeed addGlobalMapping should not work with
MCJIT.
MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols.
Instead it uses RTDyldMemoryManager::getSymbolAddress which checks
with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of
DynamicLibrary::addSymbol is better as it should work with both JIT and
MCJIT.
Another options