similar to: [LLVMdev] MCJIT and recursive finalization

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

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

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

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero.

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of

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

Some time ago I posted here regarding a relocation overflow on Windows (among other things), but the issue disappeared and so the thread got left. I've started this new thread because a) I didn't want to necro the old one and b) it felt like its own. I've now encountered the issue again and am noting down all the information I can get about it whilst it's happening. The issues is

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

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

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

Hi, what to do, if the kernel hangs on boot time with: megaraid: ABORTING-1 cmd=12 <c=0 t=0 l=0> megaraid: ABORTING-1[d7] fw owner Konrad Naumann _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Motivation === Over the last decade we have developed an interactive, interpretative C++ (aka REPL) as part of the high-energy physics (HEP) data analysis project -- ROOT [1-2]. We invested a significant  effort to replace the CINT C++ interpreter with a newly implemented REPL based on llvm -- cling [3]. The cling infrastructure is a core component of the data analysis framework of ROOT and

Hi, we want to implement a C++ interpreter using LLVM and clang, to replace our existing one <http://root.cern.ch/drupal/content/cint> that is used as part of a data handling and analysis environment <http://root.cern.ch>. We plan to keep the set of features that our current interpreter offers, e.g. calls into and out of libraries, dynamic scoping, unloading of code, and a prompt. I

Hi Richard, On 7/10/20 11:10 PM, Richard Smith wrote: > Hi Vassil, > > This is a very exciting proposal that I can imagine bringing important > benefits to the existing cling users and also to the clang user and > developer community. Thank you for all the work you and your team have > done on cling so far and for offering to bring that work under the > LLVM umbrella!

I like cling, and having it integrated with the rest of the project would be neat. I agree with Hal’s suggestion to explain the design of what remains. It sounds like a pretty small amount of code. > On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I think that it would be great to have infrastructure for incremental C++ compilation,

On 7/10/20 1:57 PM, Vassil Vassilev wrote: > On 7/10/20 6:43 AM, JF Bastien wrote: >> I like cling, and having it integrated with the rest of the project >> would be neat. I agree with Hal’s suggestion to explain the design of >> what remains. It sounds like a pretty small amount of code. > > >   JF, Hal, did you mean you want a design document of how cling in >

2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: > we want to implement a C++ interpreter using LLVM and clang Isn't clang going on that direction anyway? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

Dear Sir/Madam Our company, 4Js software, has developed an SQL data base software that runs under different operating systems: Windows, Linux, Mac OS X. This software compiles each SQL statement into a C program that is compiled "on the fly" and executed by our JIT, Just In Time compiler. We wanted to port it to Apple's iOS, and spent a lot of time retargetting the JIT for

https://bugs.freedesktop.org/show_bug.cgi?id=89186 Bug ID: 89186 Summary: Artifacts after waking up from suspend Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: