search for: loadobjectimpl

...On 13.01.2015 00:30, Keno Fischer wrote: > Hi Axel, > > the problem is that weak symbols are not handled in RuntimeDyld at all. > The proper solution is probably to add a separate case for weak symbols > (where we're already taking care of common symbols) in > RuntimeDyld::loadObjectImpl and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. > > Please let me know if you're planning to work on a patch for this, > otherwise I'll have a go tomorrow. > > Thanks, > Keno > > On Mon, Jan 12, 2015 at 11:45 A...

...mory manager if needsToReserveEHFrames() is true. This seems at a high-level the most straightforward fit for the LLILC requirement, but I don't know if for other targets it would even be possible to move the identification of EH frames (which depends on the 'LocalSections' computed in loadObjectImpl) to before calling reserveAllocationSpace. I also don't know if that would be an undesirable "tight coupling" of RuntimeDyld with CoreCLR's particular interface. (and note that this is really two options, in that the code to separate out the per-function EH frame contribution cou...

...problem I ran into is that symbols for jitted inline functions cannot be resolved. Both LLVM and Clang are checked out with latest master branch. It is probably me that is doing something wrong but I cannot figure out what it is. Here is what I found so far. In the file RuntimeDyld.cpp in function loadObjectImpl, a check is made whether a particular function is weak or not. Since inline functions are weak (as I understood it) an attempt is made to promote this symbol to a strong definition. But only if it is present in the "ResponsibilitySet", that check is made on line 273. However, the inline f...

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #ifdef BUILD_SHARED int compareAddr(int* mcjit) { if (mcjit

...mory manager if needsToReserveEHFrames() is true. This seems at a high-level the most straightforward fit for the LLILC requirement, but I don't know if for other targets it would even be possible to move the identification of EH frames (which depends on the 'LocalSections' computed in loadObjectImpl) to before calling reserveAllocationSpace. I also don't know if that would be an undesirable "tight coupling" of RuntimeDyld with CoreCLR's particular interface. (and note that this is really two options, in that the code to separate out the per-function EH frame contribution cou...

...sToReserveEHFrames() is true. This seems at a > high-level the most straightforward fit for the LLILC requirement, but I > don't know if for other targets it would even be possible to move the > identification of EH frames (which depends on the 'LocalSections' computed > in loadObjectImpl) to before calling reserveAllocationSpace. I also don't > know if that would be an undesirable "tight coupling" of RuntimeDyld with > CoreCLR's particular interface. (and note that this is really two options, > in that the code to separate out the per-function EH frame c...

...mory manager if needsToReserveEHFrames() is true. This seems at a high-level the most straightforward fit for the LLILC requirement, but I don't know if for other targets it would even be possible to move the identification of EH frames (which depends on the 'LocalSections' computed in loadObjectImpl) to before calling reserveAllocationSpace. I also don't know if that would be an undesirable "tight coupling" of RuntimeDyld with CoreCLR's particular interface. (and note that this is really two options, in that the code to separate out the per-function EH frame contribution cou...

...at symbols for jitted inline functions cannot > be resolved. Both LLVM and Clang are checked out with latest master branch. > > It is probably me that is doing something wrong but I cannot figure out > what it is. Here is what I found so far. In the file RuntimeDyld.cpp in > function loadObjectImpl, a check is made whether a particular function is > weak or not. Since inline functions are weak (as I understood it) an > attempt is made to promote this symbol to a strong definition. But only if > it is present in the "ResponsibilitySet", that check is made on line 273. > H...

...mory manager if needsToReserveEHFrames() is true. This seems at a high-level the most straightforward fit for the LLILC requirement, but I don't know if for other targets it would even be possible to move the identification of EH frames (which depends on the 'LocalSections' computed in loadObjectImpl) to before calling reserveAllocationSpace. I also don't know if that would be an undesirable "tight coupling" of RuntimeDyld with CoreCLR's particular interface. (and note that this is really two options, in that the code to separate out the per-function EH frame contribution cou...

...9E68EEE88 0x00000079E68EEC98 0x00000079E68EEC78), llvm::object::SectionRef::getContents() + 0x55 bytes(s), c:\llvm\llvm\include\llvm\object\objectfile.h , line 375 + 0x2D byte(s) 0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld \runtimedyld.cpp, line 186 + 0x25 byte(s) 0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 0x00000079E6A4AC40 0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() + 0x3C bytes(s), c:\llvm\llvm\lib\executionengine\runtimed...

...mory manager if needsToReserveEHFrames() is true. This seems at a high-level the most straightforward fit for the LLILC requirement, but I don't know if for other targets it would even be possible to move the identification of EH frames (which depends on the 'LocalSections' computed in loadObjectImpl) to before calling reserveAllocationSpace. I also don't know if that would be an undesirable "tight coupling" of RuntimeDyld with CoreCLR's particular interface. (and note that this is really two options, in that the code to separate out the per-function EH frame contribution cou...

...79E68EEC98 0x00000079E68EEC78), llvm::object::SectionRef::getContents() + 0x55 bytes(s), c:\llvm\llvm\include\llvm\object\objectfile.h >> , line 375 + 0x2D byte(s) >> 0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld >> \runtimedyld.cpp, line 186 + 0x25 byte(s) >> 0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 0x00000079E6A4AC40 0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() + 0x3C bytes(s), c:\llvm\llvm\lib\execut...

...:SectionRef::getContents() + 0x55 bytes(s), >> c:\llvm\llvm\include\llvm\object\objectfile.h >> >> , line 375 + 0x2D byte(s) >> >> 0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 >> 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), >> llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s), >> c:\llvm\llvm\lib\executionengine\runtimedyld >> >> \runtimedyld.cpp, line 186 + 0x25 byte(s) >> >> 0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 >> 0x00000079E6A4AC40 0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() >...

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

Thanks for the link! There’s some code there that looks extremely relevant to say the least. > On 1 Oct 2015, at 19:00, Hayden Livingston <halivingston at gmail.com> wrote: > > Maybe looking at their code might help: > > https://github.com/dotnet/llilc/blob/dd12743f9cdb5418f1c39b2cd756da1e8396a922/lib/Jit/LLILCJit.cpp#L299 > > On Thu, Oct 1, 2015 at 10:45 AM, David

...079E68EEC78), llvm::object::SectionRef::getContents() + 0x55 bytes(s), c:\llvm\llvm\include\llvm\object\objectfile.h >> >> , line 375 + 0x2D byte(s) >> >> 0x00007FF65EA1E516 (0x00000079E6A5DEA0 0x00000079E68EEFF0 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyldImpl::loadObjectImpl() + 0x4D6 bytes(s), c:\llvm\llvm\lib\executionengine\runtimedyld >> >> \runtimedyld.cpp, line 186 + 0x25 byte(s) >> >> 0x00007FF65EA431AC (0x00000079E6A5DEA0 0x00000079E68EF708 0x00000079E6A4AC40 0x00000079E68EF0C8), llvm::RuntimeDyldCOFF::loadObject() + 0x3C bytes(s), c:\ll...