search for: runtimedyldcoff

...work for types > loaded from object files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up correctly? > I set ProcessAllSections = true, but I didn't recognize any change. I > found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF > and MachO versions. The function call's comment reads "Give the > subclasses a chance to tie-up any loose ends" -- possibly missing > functionality? > Unfortunately I don't have a windows machine to test on, so it's di...

...;> >> >> <snip> >> >> Do you think it is possible that RuntimeDyLd misses type info data in >>> the COFF file or doesn't wire it up correctly? >>> I set ProcessAllSections = true, but I didn't recognize any change. I >>> found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF >>> and MachO versions. The function call's comment reads "Give the >>> subclasses a chance to tie-up any loose ends" -- possibly missing >>> functionality? >>> >> >> Unfortunately I don'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 any function from these header file except the processRelocationRef()...

Thanks for the reply. I was just asking about in general whatever header files are there in Targets/ for different architectures are not including any function except this processRelocationRef() to be used in RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp and i think these files are the ones which are actually doing the relocation and linking work. So what purpose do these header files inside Targets/ actually serve. Also they include exception handling in form of exception frames, So can u guide on this issue ? Thanks,...

...leformat, OS and processor architecture). >>> >>> -- >>> Mats >>> >>> >>> On 20 April 2017 at 14:04, Siddharth Shankar Swain < >>> h2015096 at pilani.bits-pilani.ac.in> wrote: >>> >>>> So RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp >>>> are doing relocation and linking for specific object file format and all >>>> architectures using that object file format. Am i correct? If that is so >>>> then these .cpp files are not using any header file in Targets/ so what...

...e JITEventListeners support patch in https://reviews.llvm.org/D75838 will be (re)committed along with some example code as soon as I work out the kinks in the object buffer ownership -- Hopefully Monday or Tuesday this week. LLJIT now enables exception handling for MachO by default (7266a8bfeb8). RuntimeDyldCOFF will now build stubs for dllimports (337e131ca7de). JITLink now correctly scopes MachO linker-private symbols (b64afadf306, 9c9eb60b4b), and reads the 'weak' flag from the correct nlist field (c700e0317c2). Stackmaps and DWARF can now be used in the same file without triggering an asserti...

...gt;>> -- >>>>> Mats >>>>> >>>>> >>>>> On 20 April 2017 at 14:04, Siddharth Shankar Swain < >>>>> h2015096 at pilani.bits-pilani.ac.in> wrote: >>>>> >>>>>> So RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp >>>>>> are doing relocation and linking for specific object file format and all >>>>>> architectures using that object file format. Am i correct? If that is so >>>>>> then these .cpp files are not using any header f...

...79E68EEFF0 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\runtimedyld\runt imedyldcoff.cpp, line 57 + 0x14 byte(s) 0x00007FF65EA1B411 (0x00000079E68EF338 0x00000079E68EF708 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyld::loadObject() + 0x221 bytes(s), c:\llvm\llvm\lib\executionengi...

...079E6A4AC40 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\runtimedyld\runt >> imedyldcoff.cpp, line 57 + 0x14 byte(s) >> 0x00007FF65EA1B411 (0x00000079E68EF338 0x00000079E68EF708 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyld::loadObject() + 0x221 bytes(s), c:\llvm\llvm...

...handle the SF_Exported symbol flag, so whenever you go searching for a symbol in the JIT on windows you have to call findSymbol with ExportedSymbolsOnly=false. Other than that I don't think usage should differ too much between platforms. On the feature support side: the JIT linker for Windows (RuntimeDyldCOFF) is less mature, so you may run into unimplemented features there. While I don't have much time to work on Windows support myself, we definitely want to improve support for it so patches, bug reports and feature requests are all very welcome. In case it's useful too, here's a link to t...

...m::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\runtimedyld\runt >> >> imedyldcoff.cpp, line 57 + 0x14 byte(s) >> >> 0x00007FF65EA1B411 (0x00000079E68EF338 0x00000079E68EF708 >> 0x00000079E6A4AC40 0xCCCCCCCCCCCCCCCC), llvm::RuntimeDyld::loadObj...

...SF_Exported symbol flag, so whenever you go searching for a symbol in the JIT on windows you have to call findSymbol with ExportedSymbolsOnly=false. Other than that I don't think usage should differ too much between platforms. > > On the feature support side: the JIT linker for Windows (RuntimeDyldCOFF) is less mature, so you may run into unimplemented features there. While I don't have much time to work on Windows support myself, we definitely want to improve support for it so patches, bug reports and feature requests are all very welcome. > > In case it's useful too, here's a...

...the reference. Nice - but than > "??_Etype_info@@UEAPEAXI at Z" was missing too. Ufff! I decided to ignore > this. Because, when I try to load every .lib and .obj provided by Visual > Studio, I get an assertion failure with "Relocation type not implemented > yet!". RuntimeDyldCOFF is missing a lot of relocation support. We need a COFF expert to fix that and unfortunately I'm not one. I decided to have a look at "_CxxThrowException". I inserted my own > function for the JIT and had a look at the parameters. I got two of them. > The first was the address o...

Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow. Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows? -- lg > On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Larry, > > You're basically there, but you're hitting

...- but than >> "??_Etype_info@@UEAPEAXI at Z" was missing too. Ufff! I decided to ignore this. >> Because, when I try to load every .lib and .obj provided by Visual Studio, I >> get an assertion failure with "Relocation type not implemented yet!". > > > RuntimeDyldCOFF is missing a lot of relocation support. We need a COFF > expert to fix that and unfortunately I'm not one. > >> I decided to have a look at "_CxxThrowException". I inserted my own >> function for the JIT and had a look at the parameters. I got two of them. >> T...

> I tried loading the "msvcrt.lib" as a archive. That was... a bad idea! > I get a Exception while loading: > Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation > overflow", file > \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81 It's a limitation of the COFF/PE format and unrelated to exceptions. This patch explains it and shows a workaround: https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f > Is there no hope left? Well at least I am not aware of a solution....

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

...u know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced inside of the COFF::IMAGE_REL_AMD64_ADDR64 case of resolveRelocation inside RuntimeDyldCOFFx86_64. I took a look at the link provided earlier and noticed a few things... - LLILC provides a resolver that simply returns UINT64_MAX for any given symbol, which the comment explains indicates means that we want to skip relocation resolution and that the client code will handle it manually. - r...

...f! I decided to ignore >> >> this. >> >> Because, when I try to load every .lib and .obj provided by Visual >> >> Studio, I >> >> get an assertion failure with "Relocation type not implemented yet!". >> > >> > >> > RuntimeDyldCOFF is missing a lot of relocation support. We need a COFF >> > expert to fix that and unfortunately I'm not one. >> > >> >> I decided to have a look at "_CxxThrowException". I inserted my own >> >> function for the JIT and had a look at the param...

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==