search for: relocationtable

...; sections only. Mips requires to use the "rel" format. So we need to be able to select format and names of relocation section, names of symbols like __rela_iplt_* / __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. My current idea: - Add two virtual functions DefaultLayout::createDynamicRelocationTable() and DefaultLayout::getPLTRelocationTable(). Call these functions when we need to create relocation tables. By default these function create .rela.* sections. - Override createDynamicRelocationTable() and getPLTRelocationTable() in the MipsTargetLayout to create .rel.* sections. - Add support for...

...to use the "rel" format. So we need to be able to select format and > names of relocation section, names of symbols like __rela_iplt_* / > __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. > > My current idea: > - Add two virtual functions > DefaultLayout::createDynamicRelocationTable() and > DefaultLayout::getPLTRelocationTable(). Call these functions when we > need to create relocation tables. By default these function create > .rela.* sections. > - Override createDynamicRelocationTable() and getPLTRelocationTable() > in the MipsTargetLayout to create .rel.* sec...

...really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) class FnDescriptor { StringRef name; FunctionType fnType; LinkageType linkage; }; class FnState { llvm::Module* definedModule; /* maybe a llvm::ObjectImage* ? */ List<RelocationTable*>* users, void* currentPointer }; map<FnDescriptor, FnState> it could be really useful. Let's imagine the same scenario with f that calls g while g is not yet compiled. At the beginning of this scenario, "g" "void ()" could simply be associated to a FnState with...

...really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) class FnDescriptor { StringRef name; FunctionType fnType; LinkageType linkage; }; class FnState { llvm::Module* definedModule; /* maybe a llvm::ObjectImage* ? */ List<RelocationTable*>* users, void* currentPointer }; map<FnDescriptor, FnState> it could be really useful. Let's imagine the same scenario with f that calls g while g is not yet compiled. At the beginning of this scenario, "g" "void ()" could simply be associated to a FnState with...

...If MCJIT could have a map like this (I give a pseudo-c++ code) > > class FnDescriptor { > StringRef name; > FunctionType fnType; > LinkageType linkage; > }; > > class FnState { > llvm::Module* definedModule; > /* maybe a llvm::ObjectImage* ? */ > List<RelocationTable*>* users, > void* currentPointer > }; > > map<FnDescriptor, FnState> > > it could be really useful. Let's imagine the same scenario with f that calls g while g is not yet compiled. At the beginning of this scenario, "g" "void ()" could simply be...

...gt; MCJIT could have a map like this (I give a pseudo-c++ code) > > class FnDescriptor { > StringRef name; > FunctionType fnType; > LinkageType linkage; > }; > > class FnState { > llvm::Module* definedModule; > /* maybe a llvm::ObjectImage* ? */ > List<RelocationTable*>* users, > void* currentPointer > }; > > map<FnDescriptor, FnState> > > it could be really useful. Let's imagine the same scenario with f that > calls g while g is not yet compiled. At the beginning of this > scenario, "g" "void ()" coul...

...a pseudo-c++ code) >> >> class FnDescriptor { >> StringRef name; >> FunctionType fnType; >> LinkageType linkage; >> }; >> >> class FnState { >> llvm::Module* definedModule; >> /* maybe a llvm::ObjectImage* ? */ >> List<RelocationTable*>* users, >> void* currentPointer >> }; >> >> map<FnDescriptor, FnState> >> >> it could be really useful. Let's imagine the same scenario with f that >> calls g while g is not yet compiled. At the beginning of this >> scenario, "g&...

...; class FnDescriptor { >>> StringRef name; >>> FunctionType fnType; >>> LinkageType linkage; >>> }; >>> >>> class FnState { >>> llvm::Module* definedModule; >>> /* maybe a llvm::ObjectImage* ? */ >>> List<RelocationTable*>* users, >>> void* currentPointer >>> }; >>> >>> map<FnDescriptor, FnState> >>> >>> it could be really useful. Let's imagine the same scenario with f that >>> calls g while g is not yet compiled. At the beginning of this...

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

...; class FnDescriptor { >>> StringRef name; >>> FunctionType fnType; >>> LinkageType linkage; >>> }; >>> >>> class FnState { >>> llvm::Module* definedModule; >>> /* maybe a llvm::ObjectImage* ? */ >>> List<RelocationTable*>* users, >>> void* currentPointer >>> }; >>> >>> map<FnDescriptor, FnState> >>> >>> it could be really useful. Let's imagine the same scenario with f >>> that calls g while g is not yet compiled. At the beginning of thi...

...gt; StringRef name; >>>> FunctionType fnType; >>>> LinkageType linkage; >>>> }; >>>> >>>> class FnState { >>>> llvm::Module* definedModule; >>>> /* maybe a llvm::ObjectImage* ? */ >>>> List<RelocationTable*>* users, >>>> void* currentPointer >>>> }; >>>> >>>> map<FnDescriptor, FnState> >>>> >>>> it could be really useful. Let's imagine the same scenario with f >>>> that calls g while g is not yet compil...

...gt; StringRef name; >>>> FunctionType fnType; >>>> LinkageType linkage; >>>> }; >>>> >>>> class FnState { >>>> llvm::Module* definedModule; >>>> /* maybe a llvm::ObjectImage* ? */ >>>> List<RelocationTable*>* users, >>>> void* currentPointer >>>> }; >>>> >>>> map<FnDescriptor, FnState> >>>> >>>> it could be really useful. Let's imagine the same scenario with f >>>> that calls g while g is not yet compi...

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but