similar to: Re: wine in a domU

Thread stealing is not nice, even if the subject is generic. > Related question - what physical device does /dev/xvc0 refer to? What can > I > connect to get to the agetty running on this device? > xvc0 is a xen virtual console and does not correspond directly to a physical device that I am aware of. Yves-Gaël Chény seemed to have answered the second part of the question: >

Hi, I have the solution to my problem :). And the llvm gc infrastructure can work with the current MCJIT without any change (good news). I will explain what I have done to find the garbage collector metadata generated by llvm with MCJIT, I'm pretty sure that it could help someone. And it's very easy. You just have to activate a static gcprinter for the assembly. A very good example is

Hi! I have now a more precise question, I hope that this time, someone will be able to help me :) I'm now able to find the gc meta data. To find this data, I simply register a GCMetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that

I am trying to get a USB printer to work in a Linux domU. I am using Xen 3.0.3 and the Xen Linux kernel 2.6.16.40. I have hidden the USB controller''s PCI devices from dom0 and exported them to domU, and build the domU kernel with the necessary device support. When I boot the xenU kernel, it lists an error from the USB printer class code that allocating a write buffer failed. This is an 8k

Hi Gaël, Multiple module support should be fully functional. However, there are some oddities in how MCJIT gets memory ready to execute, particularly if you are using the deprecated getPointerToFunction or runFunction methods. If you use these methods you'll need to call finalizeObject before you execute the code. I've heard reports that there's a bug doing that after adding

Hi Andrew, Thank you very much for all your help! So, I have tested without my shared library (with a relocatable object and without) and still, my code is not executable. I was testing my code with multiple modules and I don't now if using multiple modules is fully functional? Anyway, I'm now allocating a mcjit for each function to be sure. But now, I have a new problem that comes

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-4 Severity: normal Xen Networking[1] works by creating a new pair of virtual ethernet interfaces (vifN.M in dom0 and ethM in domU with id N) and connecting then by an internal "crossover ethernet cable". My understanding of the "internal crossover" thing is that networking statistics should be the same no matter if you measure

Hump, I think that I have to solution, but I have a new problem (more serious). For the solution, it's stupid, I have simply loaded the shared library in ObjectCache::getObject directly in a MemoryBuffer :) As the linker understand a .o, it understands a .so. Now, I'm able to compile a module (I call finalizeObject()), I'm able to find my first generated function pointer, but I'm

control: reassign -1 xen-hypervisor-4.8-amd64 On Sat, 2018-01-06 at 15:23 +0100, Valentin Vidic wrote: > On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote: > > According to that link, the fix seems to be configuration rather than > > code. > > Does this mean this bug against the kernel should be closed? > > Yes, the problem seems to be in the Xen

Hi all, So, MCJIT is working with vmkit, that's great. However, I need to retrieve the GCModuleInfo and the MachineCodeEmitter used during the compilation process. And I don't know how I should proceed? I'm trying to understand how they are preserved with the old jit, but I have to say that I'm a little bit lost because I haven't a global view of the code... So, any help would

Hi Gaël, I would guess that MCJIT is probably attempting to load and link the shared library you return from the ObjectCache in the way it would load and link generated code, which would be wrong for a shared library. I know it seems like it should be easier to handle a shared library than a raw relocatable object (and it probably is) but MCJIT doesn't handle that case at the moment. The

Is there a particular revision in the repository that I can checkout and work from? Thanks, -- Adam On Thu, Nov 21, 2013 at 3:46 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Ok, I have exactly the same problem when I compile, I will try to > understand where is the problem. > > Gaël > > 2013/11/21 Gaël Thomas <gael.thomas00 at gmail.com>: >> Arg, you

Hi Gaël, I'm glad to hear that MCJIT looks promising to you. > I understand the point. Probably that providing a small example that describes how using > advanced features of MCJIT could help. If I can manage to make MCJIT works with VMKit, > I'll be happy to send you an example of lazy compilation that highlight some of the features > of MCJIT. I'd love to have a

Hi Andy, I have been following Julia with interest, as it's a type-optional language designed to be as nice as dynamic languages but run at the speed of compiled C++ programs. They achieve this by deducing as many types at compile time and JITing code for the unknown types at runtime when they are known. That's a smart use of a JIT. In C++ terms it's analog to instantiating templates

patchpoint is intended to be used in VMs that do their own linking, and so you wouldn't expect the function parameter to be resolved by LLVM. Presumably, in VMKit, you could just plant a pointer constant to the function you wish to call initially? -Filip On Dec 17, 2013, at 2:42 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Hi all, > > I'm trying to play with

Hi Gaël, Thank you for the detailed explanation. It's very helpful. All of the things you describe could be done within MCJIT, but I'm not sure that's where they belong. We had a discussion about lazy function compilation at the LLVM Developers Meeting last week and the consensus among those present was that it would be better to leave this sort of lazy compilation to the MCJIT

Hi Andrew (hi all:)), I perfectly understand the problem of relocation and it's really not a problem in my case. I'm still trying to make MCJIT runs but I face a small problem. I have to insert callback to the runtime for functions provided by vmkit (for example, a gcmalloc function to allocate memory from the heap). With the old JIT, VMKit simply loads a large bc file that contains all

Oups, sorry for the mistake, llcj (not llc:)) is not more maintained! Gaël Le 10 sept. 2014 00:27, "Gaël Thomas" <gael.thomas00 at gmail.com> a écrit : > Hi Brian, > > So, I confirm, llc is not more maintained. And using vmjc is probably > the good starting point to translate Java bytecode into llvm bitcode. > > However, I think that your hack (changing the way

Hi Yaron, I think a lot of what I said in my reply to Gaël also applies to your situation. In particular, I think that it's probably best for your code to manager the function stubs and replacement. I talked last week with a developer who works on the Julia language (which shares a lot of features your situation) and it's my understanding that the Julia runtime handles function stubs

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could