search for: rtdyld

...e disassembler though. I like the idea of adding some special syntax to disassemble an instruction at a label and use one of its immediates. That would eliminate a lot of the bit bashing that would have been required on instruction sets with tricky immediate encodings (E.g. ARM). Something like: # rtdyld-check: @test_inst[0] = foo - (test_inst + 5) test_inst: callq foo Cheers, Lang. > On Jun 23, 2014, at 5:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> On Mon, Jun 23, 2014 at 3:01 PM, Lang Hames <lhames at gmail.com> wrote: >> Hi Everyone, >> >...

...we can get at the immediate for the call. The " + 1" expression skips the call opcode (we know the size of the opcode ahead of time, since this is assembly and so target-specific). To verify that constraints expressed in this language hold, we can add an expression evaluator to the llvm-rtdyld utility, which is a command-line interface to RuntimeDyld. I find these things are easier to discuss in the concrete, so I've attached a basic implementation of this idea. The following discussion is in terms of my patch, but I'm very open to tweaking all this. The language I've imple...

...sistently, and since that comes before terms of where it happens in the compilation / JIT’ing process, I can’t get to the part where I see the relocation issue in clang.exe rather than my own program. clang.exe -c "Y:\Documents\Visual Studio 2013\Projects\NewProject\Source\main.cpp" llvm-rtdyld.exe" -execute main.o -dylib=C:\Windows\System32\msvcr120d.dll It also occurs with -mcmodel=large specified. The exact output of the second command, llvm-rtdyld, is as follows... Assertion failed: (Sec->Characteristics & COFF::IMAGE_SCN_CNT_UNINITIALIZED_DATA) == 0 && "BS...

...omes before terms of where it happens in the compilation / JIT’ing process, I can’t get to the part where I see the relocation issue in clang.exe rather than my own program. >> >> clang.exe -c "Y:\Documents\Visual Studio 2013\Projects\NewProject\Source\main.cpp" >> llvm-rtdyld.exe" -execute main.o -dylib=C:\Windows\System32\msvcr120d.dll >> >> It also occurs with -mcmodel=large specified. >> >> The exact output of the second command, llvm-rtdyld, is as follows... >> >> Assertion failed: (Sec->Characteristics & COFF::IMAG...

...ion / >> JIT’ing process, I can’t get to the part where I see the relocation issue >> in clang.exe rather than my own program. >> >> >> >> clang.exe -c "Y:\Documents\Visual Studio >> 2013\Projects\NewProject\Source\main.cpp" >> >> llvm-rtdyld.exe" -execute main.o >> -dylib=C:\Windows\System32\msvcr120d.dll >> >> >> >> It also occurs with -mcmodel=large specified. >> >> >> >> The exact output of the second command, llvm-rtdyld, is as follows... >> >> >> >>...

...specific. For other properties (e.g. "weak") llvm-objdump and llvm-nm suffice, since they query the generic flags to produce their (format specific) output. If "exported" is of interest to people I could add it to one of the generic tools. Otherwise I'll just add it to llvm-rtdyld. - Lang. On Sun, Jan 24, 2016 at 4:16 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Sun, Jan 24, 2016 at 2:47 PM, Lang Hames via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Rui, Rafael, Kevin, Nick, >> >> In r258665 I a...

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

...it happens in the compilation / JIT’ing process, I can’t get to the part where I see the relocation issue in clang.exe rather than my own program. >> >> >> >> clang.exe -c "Y:\Documents\Visual Studio 2013\Projects\NewProject\Source\main.cpp" >> >> llvm-rtdyld.exe" -execute main.o -dylib=C:\Windows\System32\msvcr120d.dll >> >> >> >> It also occurs with -mcmodel=large specified. >> >> >> >> The exact output of the second command, llvm-rtdyld, is as follows... >> >> >> >> Assertio...

...public: ConcreteLinkedObjectSet(MemoryManagerPtrT MemMgr, SymbolResolverPtrT Resolver) : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), Resolver(std::move(Resolver)) { } void Finalize() override { State = Finalizing; RTDyld->resolveRelocations(); RTDyld->registerEHFrames(); MemMgr->finalizeMemory(); OwnedBuffers.clear(); State = Finalized; } From: Lang Hames [mailto:lhames at gmail.com] Sent: Friday, July 3, 2015 6:36 PM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com&...

...> SymbolResolverPtrT Resolver) > > : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), > > Resolver(std::move(Resolver)) { } > > > > void Finalize() override { > > State = Finalizing; > > RTDyld->resolveRelocations(); > > RTDyld->registerEHFrames(); > > MemMgr->finalizeMemory(); > > OwnedBuffers.clear(); > > State = Finalized; > > } > > > > > > *From:* Lang Hames [mailto:lhames at gmail.com] > *Sent:* F...

...public: ConcreteLinkedObjectSet(MemoryManagerPtrT MemMgr, SymbolResolverPtrT Resolver) : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), Resolver(std::move(Resolver)) { } void Finalize() override { State = Finalizing; RTDyld->resolveRelocations(); RTDyld->registerEHFrames(); MemMgr->finalizeMemory(); OwnedBuffers.clear(); State = Finalized; } From: Lang Hames [mailto:lhames at gmail.com<mailto:lhames at gmail.com>] Sent: Friday, July 3, 2015 6:36 PM To: Eugene Rozenfeld <...

...r: Let x be a pointer to r_offset of appropriate size given by r_size, then *x += addr_of_symbol(r_symbolnum) However, when r_extern=0 the correct behavior is not clear. By analogy with the above, I would have expected *x += addr_of_section(r_symbolnum) but what LLVM implements is different. In RTDyld it implements *x = (*x-addr_of_section(r_symbolnum)) + addr_of_section(r_symbolnum) or equivalently *x = *x i.e. a noop. This works because llvm codegen also emits the absolute value of the address. I am unsure what is intended and would appreciate some clarification. A couple of points to cons...

Hi Matt, Philip, You could get the data you want by recording the addresses returned by the allocateCodeSection and allocateDataSection methods on your RTDyldMemoryManager, then disassembling those sections after you've called resolveRelocations. That's a little unsatisfying though. For one thing, unless you very carefully maintain the association with the original object via back-channels there will be no way of knowing which section belongs to...

...> SymbolResolverPtrT Resolver) > > : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), > > Resolver(std::move(Resolver)) { } > > > > void Finalize() override { > > State = Finalizing; > > RTDyld->resolveRelocations(); > > RTDyld->registerEHFrames(); > > MemMgr->finalizeMemory(); > > OwnedBuffers.clear(); > > State = Finalized; > > } > > > > > > *From:* Lang Hames [mailto:lhames at gmail.com] > *Sent:* F...

...and restored if needed? I was thinking, maybe I am mistaken, that the plan was to write code in memory as ELF which can be exported/imported as such. Is this the case? The current implementation uses MachO binaries in memory. There's no reason they couldn't be serialized to disk. The llvm-rtdyld tool gives an example of using the MCJIT RuntimeDyld support to load an object file from memory and use it directly. The idea is that the object module will be loaded/JITed, then registered with the RuntimeDyld which will extract the functions, data, etc.. from the object and register them with th...

hello folks, I'm working to add runtime updating of code to the OCaml compiler which in its bytecode guise presents no barrier because there is only one linker and it is written in that language and full control is available. With native code on the other hand, there is reliance on the system linker and I got completely lost examining the GNU ld/dl library source code. The prospect of

On 06/24/2011 13:23, Jim Grosbach wrote: >> Any progress with this? >> gitorious page shows the last update on Jul 27, 2010. >> > There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and ExecutionEngine/MCJIT. > > It's usable enough for some things; for

...emory object file image (using addPassesToEmitMC) and then loads and links it for execution. > > If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use the RuntimeDyld interface to load it. The llvm-rtdyld tool does something like this. > > -Andy > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Baris Aktemur > Sent: Thursday, October 11, 2012 11:58 PM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Dyn...

...template 464M clang-rename 462M clang-reorder-fields 460M find-all-symbols 456M clang-doc 452M clang-include-fixer 444M modularize 443M clang-func-mapping 442M clang-diff 441M libToolingExample00 438M pp-trace 434M diagtool 184M llvm-cfi-verify 170M llvm-objdump 168M sancov 158M llvm-rtdyld 149M llvm-ar 148M llvm-nm 145M llvm-extract 145M llvm-link 142M llvm-dwarfdump 141M llvm-split 131M llvm-mc 127M llvm-pdbutil 126M clang-offload-bundler 122M llvm-mca 121M verify-uselistorder 121M llvm-cat 120M llvm-as 117M llvm-special-case-list-fuzzer 117M llvm-demangle-fuzzer 116...

...IA. Ashok -------------- next part -------------- ==================CMake artifacts==================== ashoknn at wk:/local/mnt/workspace/llvm/bin.stock$l * bin: bugpoint* clang++@ diagtool* llvm-ar* llvm-config* llvm-dis* llvm-ld* llvm-mc* llvm-prof* llvm-rtdyld* llvm-stub* opt* c-index-test* clang-3.1* llc* llvm-as* llvm-cov* llvm-dwarfdump* llvm-link* llvm-nm* llvm-ranlib* llvm-size* llvm-tblgen* clang@ clang-tblgen* lli* llvm-bcanalyzer* llvm-diff* llvm-extract* llvm-lit* llvm-objdump* ll...