similar to: [LLVMdev] Proposal: Improved regression test support for RuntimeDyld/MCJIT.

Hi Dave, Jim Grosbach asked the same question, so you're in good company. With hindsight I think it was a mistake to say "FileCheck workflow". What I really meant was that this system plays well with lit. Not that your question about using FileCheck would have been any less valid. I did consider using FileCheck for this, but decided it was the wrong approach. The fundamental reason

It’s pretty intermittent at the moment…sometimes I get the relocation overflow issue, sometimes I get another issue about BSS sections having no contents. The source code to reproduce either is simple: #include <iostream> int main (int argc, char* argv[]) { } I’ve managed to reproduce the BSS section issue in clang consistently, and since that comes before terms of where it happens in

Oops, sorry for the spam. That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5 > On 5 Oct 2015, at 17:26, Joshua Gerrard <joshua.gerrard at roli.com> wrote: > > Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5 > >> On 5 Oct 2015, at 17:16, Joshua Gerrard <joshua.gerrard at roli.com> wrote: >>

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated

Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations. I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames. I understand that

On Jun 29, 2011, at 4:36 PM, Yuri wrote: > 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

Hi Eugene, Sorry for the delayed reply. Custom relocations weren't something I had in mind when I designed Orc, so they raise some interesting design questions which I don't have good answers to yet. (E.g. The interface for the Orc layer concept assumes that there's a RuntimeDyld instance embedded at the bottom of the stack. That's why addModuleSet takes a MemoryManager and

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

First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you 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

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

Hi Eugene, Skipping the call to resolveRelocations would disable many (if not all) internal relocations too. Is that the desired behavior? At that point there's not much left for RuntimeDyld (or the ObjectLinkingLayer) to do. Would something like a NoopLinkingLayer be a workable solution? Cheers, Lang. On Wed, Jul 22, 2015 at 7:26 PM, Eugene Rozenfeld < Eugene.Rozenfeld at

Hi llvm-community, I use llc (3.4-final) to generate object file: *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o* then I load it with *RuntimeDyld + SectionMemoryManager* in my app. I faced the problem described in 15356 <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion fails at

I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually

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

Hi Lang, It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below. The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer. I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and

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

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

Kaylor, do you have some good documented example code which shows the usage of the MCJIT ? This would help a lot ... the sematic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an

Daniel, I didn't find the MCJIT directory under unitests/ExecutionEngine ... there is only a directory called JIT. You mean this directory ? Many thanks --Armin Malea, Daniel wrote: > Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT > > The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. > >

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory 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