search for: g_stub

...of calls to g before compiling it and it means that I will have to generate a lot of different names (not a big deal, but it takes time during the execution)... > For instance, you'll probably want the module for 'f' to look something like this: > > ---- > > declare i32 @g_stub() > > define i32 @f() { > %r = call i32 @g_stub( ) > ret i32 %r > } > > ---- > > and the module for 'g' will look something like this: > > ---- > > define i32 @g() { > ret i32 0 > } > > ---- > > Now when you generate code for th...

...f 'g' will get linked to the stub and only the stub will call 'g' directly. If the calls and the implementation use the same name MCJIT will start trying to link callers directly to the implementation once it's available. > But the location of the call-site (the pointer to g_stub in the generated code) should be in the > relocation table of the module f? You don't think that a client could reuse this relocation table directly? There are a couple of problems with that. First, MCJIT gets the relocations in a slightly different form than a pure loader typically would....

...the name of the function as it appears at the call site (which will result in a call to your stub function) and the name of the function as it is defined in the implementation module. For instance, you'll probably want the module for 'f' to look something like this: ---- declare i32 @g_stub() define i32 @f() { %r = call i32 @g_stub( ) ret i32 %r } ---- and the module for 'g' will look something like this: ---- define i32 @g() { ret i32 0 } ---- Now when you generate code for the 'f' module, MCJIT will call the memory manager asking for the address of '...

...; will get linked to the stub and only the stub will call 'g' directly. If the calls and the implementation use the same name MCJIT will start trying to link callers directly to the implementation once it's available. > > >> But the location of the call-site (the pointer to g_stub in the generated code) should be in the >> relocation table of the module f? You don't think that a client could reuse this relocation table directly? > > There are a couple of problems with that. > > First, MCJIT gets the relocations in a slightly different form than a pure l...

...inked to the stub and only the stub will call 'g' directly. If the calls and the implementation use the same name MCJIT will start trying to link callers directly to the implementation once it's available. >> >> >>> But the location of the call-site (the pointer to g_stub in the generated code) should be in the >>> relocation table of the module f? You don't think that a client could reuse this relocation table directly? >> >> There are a couple of problems with that. >> >> First, MCJIT gets the relocations in a slightly differen...

...inked to the stub and only the stub will call 'g' directly. If the calls and the implementation use the same name MCJIT will start trying to link callers directly to the implementation once it's available. >> >> >>> But the location of the call-site (the pointer to g_stub in the >>> generated code) should be in the relocation table of the module f? You don't think that a client could reuse this relocation table directly? >> >> There are a couple of problems with that. >> >> First, MCJIT gets the relocations in a slightly differe...

...stub and only the stub will call 'g' directly. If the calls and the implementation use the same name MCJIT will start trying to link callers directly to the implementation once it's available. >>> >>> >>>> But the location of the call-site (the pointer to g_stub in the >>>> generated code) should be in the relocation table of the module f? You don't think that a client could reuse this relocation table directly? >>> >>> There are a couple of problems with that. >>> >>> First, MCJIT gets the relocations in...

...stub and only the stub will call 'g' directly. If the calls and the implementation use the same name MCJIT will start trying to link callers directly to the implementation once it's available. >>> >>> >>>> But the location of the call-site (the pointer to g_stub in the >>>> generated code) should be in the relocation table of the module f? You don't think that a client could reuse this relocation table directly? >>> >>> There are a couple of problems with that. >>> >>> First, MCJIT gets the relocations i...

Hi Andrew, hi all, I already saw that the old jit was (almost) deprecated. So, I'm currently playing with the new jit and it's look very interesting. (I'm working locally and I haven't pushed anything new on VMKit because I'm also changing a little the design vmkit). For the moment, MCJIT does not work with VMKit (but I haven't yet tested the safepoint/stackmap patch), I