search for: runtimedyldcoffi386

Hi, Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the header files included for different architectures like RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the connection of these files for relocation and linking as the linking and relocation for diff architecture is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp and it doesn't use any function from these header file except the processRelocationRef(). The header files in Targets/...

...April 2017 at 11:13, Siddharth Shankar Swain via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the >> header files included for different architectures like >> RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the >> connection of these files for relocation and linking as the linking and >> relocation for diff architecture is done in RuntimeDyldELF.cpp, >> RuntimeDyldCOFF.cpp and it doesn't use any function from these header file >> except the processRelocation...

...t;>>> >>>>>>>> Hi, >>>>>>>> Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the >>>>>>>> header files included for different architectures like >>>>>>>> RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the >>>>>>>> connection of these files for relocation and linking as the linking and >>>>>>>> relocation for diff architecture is done in RuntimeDyldELF.cpp, >>>>>>>> RuntimeDyldCOFF.cpp and it doesn't use a...

...oo >> >> It looks like the offset `4` of the second field of your struct is >> correct in the object file, so this does seem to be a problem in the >> JIT-specific linking/loading. >> >> Can you try debugging into lib/ExecutionEngine/Runti >> meDyld/Targets/RuntimeDyldCOFFI386.h to see if the relocation is getting >> applied correctly in the context of your JIT? >> >> You may be able to repro this more easily using `lli`. It has a >> `-jit-kind` argument that should get you into the JIT codepath. (see >> test/ExecutionEngine/{MCJIT,ORCMCJIT}...

...gt;>>>>> Hi, >>>>>>>>>> Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ >>>>>>>>>> the header files included for different architectures like >>>>>>>>>> RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the >>>>>>>>>> connection of these files for relocation and linking as the linking and >>>>>>>>>> relocation for diff architecture is done in RuntimeDyldELF.cpp, >>>>>>>>>> RuntimeDyldCOFF.cpp...

..., 4 00000054: IMAGE_REL_I386_DIR32 _foo It looks like the offset `4` of the second field of your struct is correct in the object file, so this does seem to be a problem in the JIT-specific linking/loading. Can you try debugging into lib/ExecutionEngine/RuntimeDyld/Targets/RuntimeDyldCOFFI386.h to see if the relocation is getting applied correctly in the context of your JIT? You may be able to repro this more easily using `lli`. It has a `-jit-kind` argument that should get you into the JIT codepath. (see test/ExecutionEngine/{MCJIT,ORCMCJIT}/) -- Sean Silva On Tue, Jun 6, 2017 at 1...

On Mon, Jun 5, 2017 at 1:34 PM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > Uh. Turns out that if I hide the pointer to @foo from LLVM by passing it > through an opaque identity function ... then everything works fine. > > Is this a bug in LLVM or is there some magic involving globals I'm > misunderstanding? > This looks like a bug in the handling of