similar to: Understand the meaning of preds = %0

Hi Tim, I'm still struggling on the instruction: call void bitcast (void (%struct.png_struct_def.68*, i8*, i8* (%struct.png_struct_def.68*, i64)*, void (%struct.png_struct_def.68*, i8*)*)* @png_set_mem_fn to void (%struct.png_struct_def*, i8*, i8* (%struct.png_struct_def*, i64)*, void (%struct.png_struct_def*, i8*)*)*)(%struct.png_struct_def* %create_struct, i8* %mem_ptr, i8*

Hi, I'm playing with the IR of pngpixel and I encountered this instruction: call void bitcast (void (%struct.png_struct_def.68*, i8*, i8* (%struct.png_struct_def.68*, i64)*, void (%struct.png_struct_def.68*, i8*)*)* @png_set_mem_fn to void (%struct.png_struct_def*, i8*, i8* (%struct.png_struct_def*, i64)*, void (%struct.png_struct_def*, i8*)*)*)(%struct.png_struct_def* %create_struct, i8*

Hi all, I have managed to compile libpng using wllvm and obtain the IR of pngpixel ( small tool which is part of libpng ). libpng has a function called png_check_IHDR: void /* PRIVATE */ png_check_IHDR(png_const_structrp png_ptr, png_uint_32 width, png_uint_32 height, int bit_depth, int color_type, int interlace_type, int compression_type, int filter_type) { int error = 0; /*

Hi David, My question is: why both #ifdef and #else branches are missing? I think at least one of the two should be present... In fact there is a case where the width could be greater then PNG_USER_WIDTH_MAX but not greater then PNG_UINT_31_MAX. That's why I was expecting at least one of the two... Thanks Alberto On Wed, Dec 18, 2019, 22:12 David Blaikie <dblaikie at gmail.com>

Hi all, I have encountered a weird case that I cannot understand. Inside the visitStoreInst I have a reference (F) to the function png_set_mem_fn. If I do F->dump() i can set the IR of that function correctly e.g.: ; Function Attrs: nounwind uwtable define void @png_set_mem_fn(%struct.png_struct_def.68* noalias %png_ptr, i8* %mem_ptr, i8* (%struct.png_struct_def.68*, i64)* %malloc_fn, void

--- configure.ac | 5 +++++ plugins/vddk/vddk.c | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/configure.ac b/configure.ac index d71f06e4..57626a76 100644 --- a/configure.ac +++ b/configure.ac @@ -321,6 +321,11 @@ AC_SEARCH_LIBS([dlsym], [dl dld], [ ]) LIBS="$old_LIBS" +old_LIBS="$LIBS" +LIBS="$LIBS -ldl" +AC_CHECK_FUNCS([dlmopen])

I couldn't get this to work in the end. This is the latest non-working version. This email documents what doesn't work for the permanent record. The central problem is that VDDK InitEx() appears to dlopen() various of its own plugins. Although I wasn't able to capture exactly what dlopen() command it is running, the plugins cannot be loaded because they rely on the recompiled

We had a query yesterday about the VDDK plugin and making it actually obey the weird "Multithreading Considerations" rules in the VDDK documentation (https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/vsphere-vddk-671-programming-guide.pdf) This patch is my attempt to implement this. The idea is that the

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

In v7: everything should work now! The re-exec code is slightly simplified, with Rich's suggestion to pass the original LD_LIBRARY_PATH rather than just the prefix being added, and I've now finished wiring up the initial dlopen() check into code that correctly computes the right prefix dir to add to LD_LIBRARY_PATH. Eric Blake (1): vddk: Add re-exec with altered environment Richard

Differences from v4: Patch 1 is simplified: I realized that since we already use -rdynamic for nbdkit (after all, we WANT our dlopen()d plugins to be able to call our nbdkit_* exports), it is only a matter of adding dlopen to the set of symbols that we export. With that done, there is no separate shared library needed; our dlopen shim is now part of nbdkit proper, and we don't have to tweak

I'm a lot happier with this version: no mucking with dlmopen(). It does add a bit more coupling between nbdkit proper and the vddk plugin (namely, nbdkit now exports a new function that the vddk plugin relies on), but patch 2 adds testsuite coverage of the new function so we shouldn't regress. Patch 1 and 2 are new, patch 3 is unchanged from when Rich posted it in v2, and patch 4 is

N_conreq:entry { self->x=1; calledaddr=(struct xaddrf *)arg3; callingaddr=(struct xaddrf *)arg4; trace(calledaddr->link_id); tracemem(calledaddr->DTE_MAC.lsap_add, 80); trace(callingaddr->link_id); tracemem(callingaddr->DTE_MAC.lsap_add, 80); } 0 -> N_conreq 255

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

We were previously dlopen-ing it in the load() method. This is very early and in particular means that the only possible way to configure where we find the library is through environment variables and not through config parameters. Also it's not necessary as we don't call any functions from the library (such as VixDiskLib_InitEx) until config_complete. This change is neutral refactoring

Hi, I see things like this. What does it mean? Is it documented somewhere? Thanks. ; preds = %for.body https://llvm.org/docs/LangRef.html ; <label>:91: ; preds = %88 %92 = load i8**, i8*** @glob_complete_word.matches, align 8, !dbg !99798 %93 = load i32, i32* @glob_complete_word.ind, align 4, !dbg !99799 %94 = sext i32 %93 to i64, !dbg !99798

Below is a patch to get rid of several warnings which occur while building syslinux 3.07 with the current gcc 4 snapshot. This fixes all the warnings except one unused variable. Take them or leave them as you see fit. They're all com32 stuff that's pulled in from external sources. --- syslinux-3.07/memdisk/unzip.c.gcc4 2004-12-07 23:29:22.000000000 -0500 +++