search for: opaqu

Hi all, I am creating a function and trying to call it using the LLVM API. It seems that whenever the function type includes an opaque-typed parameter, the CallInst::Create call causes an assert: Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /usr/home/csanchez/shared/prj/tce/ sr...

2009/9/15 Carlos Sánchez de La Lama <carlos.delalama at urjc.es>: > Hi all, > > I am creating a function and trying to call it using the LLVM API. It > seems that whenever the function type includes an opaque-typed > parameter, the CallInst::Create call causes an assert: > > Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) > == Params[i]->getType()) && "Calling a function with a bad > signature!"), function init, file /usr/home/csanchez/s...

When running on PowerPC, we don''t have native PIO support. There are a few hacks around to enable PIO access on PowerPC nevertheless. The most typical one is the isa-mmio device. It takes MMIO requests and converts them to PIO requests on the (QEMU internal) PIO bus. This however is not how real hardware works and it limits us in the ability to spawn eventfd''s on PIO ports

On Nov 12, 2008, at 5:07 PM, David Greene wrote: > On Wednesday 12 November 2008 18:58, Chris Lattner wrote: >> On Nov 12, 2008, at 3:37 PM, David Greene wrote: >>>>> Unfortunately, calling FunctionType::refineAbstractType(opaque, >>>>> void >>>>> (...)) >>>>> doesn't work because RefineAbstractType doesn't recurse down into >>>>> the >>>>> pointee types. >>>> >>>> What types are you starting out with? If you had t...

On Wednesday 12 November 2008 18:58, Chris Lattner wrote: > On Nov 12, 2008, at 3:37 PM, David Greene wrote: > >>> Unfortunately, calling FunctionType::refineAbstractType(opaque, void > >>> (...)) > >>> doesn't work because RefineAbstractType doesn't recurse down into > >>> the > >>> pointee types. > >> > >> What types are you starting out with? If you had the equivalent of: > >> > >...

Can anyone tell me where my blunder is in the following program? llvm-as reports: llvm-as: testit.ll:11: Can't store 'opaque *' into space of type 'opaque *'! Which doesn't seem to make sense to me. What is it that is illegal about storing a pointer to opaque in a space that is of type pointer to opaque? Is it just that you can't store pointers to opaque? %path = internal constant [11 x sbyte] c&qu...

...910 [1 x i64] Derived new type: [1 x i64] TypeMap<>::add table contents: 1. 0x3a4e6a0 i32 * 2. 0x3a4eb60 [1 x i64] * Derived new type: [1 x i64] * TypeMap<>::add table contents: 1. 0x3a4e6a0 i32 * 2. 0x3a4f140 i64 * 3. 0x3a4eb60 [1 x i64] * Derived new type: i64 * Derived new type: opaque TypeMap<>::add table contents: 1. 0x3a4e6a0 i32 * 2. 0x3a4f140 i64 * 3. 0x3a4eb60 [1 x i64] * 4. 0x3a8c310 opaque * Derived new type: opaque * TypeMap<>::add table contents: 1. 0x3a8c450 i32 (opaque *) Derived new type: i32 (opaque *) TypeMap<>::add table contents: 1. 0x3a4...

Hello LLVM, I'm playing with a new ISD::OPAQUE instruction to make hoisting first class and eliminate a lot of tweaky flag setting/checking around opaque constants. It's going well for the IR and x86, but I now I need to sort out details for all the other targets. To start, can someone please advise on the AAarch64 equivalent of these X8...

** INCOMPLETE ** This is the generator change as discussed on the list already. The Python and OCaml bindings are not yet done. It passes all [C only] tests and valgrind. Note that nbd_add_close_callback is inconsistent with other closure types because it passes the user_data parameter after the function. (This is not caused by the current patch, it was already inconsistent). We decided that

...-) diff --git a/hw/xen_platform.c b/hw/xen_platform.c index ca66047..8866468 100644 --- a/hw/xen_platform.c +++ b/hw/xen_platform.c @@ -279,7 +279,8 @@ static void platform_fixed_ioport_init(PCIXenPlatformState* s) /* Xen Platform PCI Device */ -static uint32_t xen_platform_ioport_readb(void *opaque, uint32_t addr) +static uint64_t xen_platform_ioport_readb(void *opaque, hwaddr addr, + unsigned int size) { if (addr == 0) { return platform_fixed_ioport_readb(opaque, 0); @@ -288,30 +289,28 @@ static uint32_t xen_platform_ioport_readb(void...

...r 'callback' is the best approach or most idiomatic OCaml - but hey, it taught me a lot about OCaml. Writing a 'string * callback list' proved to be a rather interesting exercise] Our C code has a couple of functions that want to take multiple callback functions that share a single opaque data (nbd_aio_pread_structured_callback; nbd_aio_block_status_callback). However, the mapping of this construct to Python passed only the opaque handle of the first function to the second callback wrapper, which means we would invoke the wrong Python Callable; better is tracking a single malloc()d...

Posting now that I got something to compile (at the expense of breaking OCaml bindings), but I'm open to ideas on how to improve it. Eric Blake (2): generator: Tweak print_c_arg_list to take alternate first arg RFC: generator: Handle shared callbacks in Python generator/generator | 556 ++++++++++++++++++++++---------------------- 1 file changed, 280 insertions(+), 276 deletions(-) --

...in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1  0x00007f0d5892176a in virCondWait (c=c@entry=0x5557f238db28, m=m@entry=0x5557f238db00) at util/virthread.c:154         ret = <optimized out> #2  0x00007f0d58922543 in virThreadPoolWorker (opaque=opaque@entry=0x5557f23848f0) at util/virthreadpool.c:124         data = 0x0         pool = 0x5557f238dac0         cond = 0x5557f238db28         priority = false         curWorkers = 0x5557f238dba0         maxLimit = 0x5557f238db88         job = 0x0 #3  0x00007f0d58921288 in virThreadHelper...

...| 31 ++++++++++++++----------------- hw/virtio.h | 4 ++++ 3 files changed, 66 insertions(+), 18 deletions(-) diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index 294f4c7..589fbb1 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -105,6 +105,48 @@ static void virtio_pci_notify(void *opaque, uint16_t vector) qemu_set_irq(proxy->pci_dev.irq[0], proxy->vdev->isr & 1); } +static void virtio_pci_save_config(void * opaque, QEMUFile *f) +{ + VirtIOPCIProxy *proxy = opaque; + pci_device_save(&proxy->pci_dev, f); + msix_save(&proxy->pci_dev, f)...

...| 31 ++++++++++++++----------------- hw/virtio.h | 4 ++++ 3 files changed, 66 insertions(+), 18 deletions(-) diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c index 294f4c7..589fbb1 100644 --- a/hw/virtio-pci.c +++ b/hw/virtio-pci.c @@ -105,6 +105,48 @@ static void virtio_pci_notify(void *opaque, uint16_t vector) qemu_set_irq(proxy->pci_dev.irq[0], proxy->vdev->isr & 1); } +static void virtio_pci_save_config(void * opaque, QEMUFile *f) +{ + VirtIOPCIProxy *proxy = opaque; + pci_device_save(&proxy->pci_dev, f); + msix_save(&proxy->pci_dev, f)...

..._cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> #1 0x00007f4129c2a2e6 in virCondWait (c=c@entry=0x7f412b18ebb8, >> m=m@entry=0x7f412b18eb90) at util/virthread.c:154 >> #2 0x00007f4129c2ada3 in virThreadPoolWorker >> (opaque=opaque@entry=0x7f412b183ab0) at util/virthreadpool.c:124 >> #3 0x00007f4129c2a078 in virThreadHelper (data=<optimized out>) at >> util/virthread.c:206 >> #4 0x00007f4127033dc5 in start_thread (arg=0x7f411a9d7700) at >> pthread_create.c:308 >> #5 0x00007f4126d...

...0x7fcf3a4e8700 (LWP 14799)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fcf4e17ee36 in virCondWait (c=c@entry=0x7fcf3400cc90, m=m@entry=0x7fcf3400cc50) at util/virthread.c:154 #2 0x00007fcf405498a0 in udevEventHandleThread (opaque=<optimized out>) at node_device/node_device_udev.c:1606 #3 0x00007fcf4e17ec02 in virThreadHelper (data=<optimized out>) at util/virthread.c:206 #4 0x00007fcf4ca26494 in start_thread (arg=0x7fcf3a4e8700) at pthread_create.c:333 #5 0x00007fcf4c768acf in clone () at ../...

...runtime library that contains some support routines called by generated code. The IR module contains calls to "malloc", which depend on the size of "size_t". Since I don't know the target when writing the IR module for the runtime library, I thought about using an "opaque" type instance in place of "size_t". When loading the IR module, I would refine the "opaque" to either i64 or i32, depending on which target I'm using. For example I currently have ; these opaque types are replaced at load time by codegen::RuntimeLib %size...

...VIRTIO_PCI_CONFIG_MSI : \ + VIRTIO_PCI_CONFIG_NOMSI) /* Virtio ABI version, if we increment this, we break the guest driver. */ #define VIRTIO_PCI_ABI_VERSION 0 @@ -81,14 +99,17 @@ typedef struct { static void virtio_pci_notify(void *opaque, uint16_t vector) { VirtIOPCIProxy *proxy = opaque; - - qemu_set_irq(proxy->pci_dev.irq[0], proxy->vdev->isr & 1); + if (msix_enabled(&proxy->pci_dev)) + msix_notify(&proxy->pci_dev, vector); + else + qemu_set_irq(proxy->pci_dev.irq[0], pr...

...VIRTIO_PCI_CONFIG_MSI : \ + VIRTIO_PCI_CONFIG_NOMSI) /* Virtio ABI version, if we increment this, we break the guest driver. */ #define VIRTIO_PCI_ABI_VERSION 0 @@ -81,14 +99,17 @@ typedef struct { static void virtio_pci_notify(void *opaque, uint16_t vector) { VirtIOPCIProxy *proxy = opaque; - - qemu_set_irq(proxy->pci_dev.irq[0], proxy->vdev->isr & 1); + if (msix_enabled(&proxy->pci_dev)) + msix_notify(&proxy->pci_dev, vector); + else + qemu_set_irq(proxy->pci_dev.irq[0], pr...