similar to: segfault calling SDL_Init with FFI/ MCJIT

Hello there, tl;dr: Is it a known behaviour that using llvm-3.4 and llvm-3.6 at the same time in the same process (while llvm-3.6 is used from a linked shared library and llvm-3.4 is dlopen'ed - with a strange detail: Especially if -rdynamic is used when linking the program). If so, is there a workaround? If not, can it be fixed in llvm-3.6? Long story: I am writing a program that creates

Hi all, OpenJDK8 jdk8u-dev[1] is just able to work after compiled with LLVM 3.9.1 for X86: $ ./build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal-debug" OpenJDK Runtime Environment (build 1.8.0-internal-debug-xiangzhai_2018_09_09_21_08-b00) OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode) $ strings

Reported https://bugs.llvm.org/show_bug.cgi?id=38911 Thanks, Leslie Zhai 在 2018年09月11日 16:55, Dimitry Andric 写道: > Hi Leslie, > > The problem really lies in the OpenJDK code, as it is attempting to > write to a const object. If this seems to work with certain compiler(s) > and optimization settings, it is just luck. :-) > > Here is a reduced example, which shows the

Hi Dimitry, Thanks for your kind response! Thanks for the commit message of Jung's patch, I found that the bug had been fixed in OpenJDK 12 by Zhengyu https://bugs.openjdk.java.net/browse/JDK-8205965 But only backported to 11. So Jung could backport it for OpenJDK 8, thanks a lot! But I argue that the root cause might be in the compiler side, why clang-3.9.1, gcc-6.4.1 couldn't

The DDX eating CPU isn't intrinsically bad. Did you check where perf says the CPU time is going? Could be doing copies/etc. On Mon, Aug 17, 2020 at 12:52 AM Andrew Randrianasulu <randrianasulu at gmail.com> wrote: > > I was testing Ilia's patches for ddx, and while they definitely helped for Xorg itself, > qemu still eats a lot of CPU if launched like this > >

I was testing Ilia's patches for ddx, and while they definitely helped for Xorg itself, qemu still eats a lot of CPU if launched like this qemu-system-x86_64 -cdrom ~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 1G -display sdl,gl=on -enable-kvm and left for few hours. top - 07:38:01 up 18:05, 2 users, load average: 2,00, 1,89, 1,83 Tasks: 224 total, 3 running, 221 sleeping, 0

Dear all, I was trying to use the R swig wrapper with R 2.7 and shogun ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't even compile and even after patching then though compiling - crashes... So I asked on swig-users/swig-devel CC'ing the potential R maintainer but I never received a reply. I now wonder if anyone here could help or would be willing to maintain

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.

Hello lldb developers, I am running into a problem with lldb on Linux. I am currently running llvm 6.0.0. I have an executable that dynamically loads a large number of shared libraries at runtime. These are explicitly loaded via dlopen (they are specified in a configuration file), and after loading a few (typically a dozen or so, but the number varies) lldb will halt during dlopen. If I

[+lldb-dev] Hello Steve, thanks for the report. The fact that you see the rendezvous breakpoint being hit many times is not surprising. We get those every time the library is loaded (we need that to load relevant debug info and set potential breakpoints). However, they should generally not be surfaced to the user (unless you have the stop-on-sharedlibrary-events setting set, which you

I rebuild mesa with debug symbols, and now top functions using CPU looks like this: CPU: AMD64 family15h, speed 3800 MHz (estimated) Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name symbol name ------------------------------------------------------------------------------- 222978 45.1489

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

I looked around for the status of OrcJIT FFI support. The last e-mail thread I could find was this one: Link <http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html> Raw: http://lists.llvm.org/pipermail/llvm-dev/2015-February/081679.html Is OrcJIT now considered stable enough that there can be "official" exposed C APIs? If not, what's the standard approach if I

Hi all, How does this look as a potential FFI for our theoretical Ruby++ ? I''m not sure how to do mixins, though. Some sort of special directive? Or just add it to inheritance chain? Anyway, this is just a rough prototype. No attempt at an actual implementation yet. Regards, Dan // foo.h - Function prototypes #define _FOO_H_ using namespace ruby; // Subclass Object class Foo :

clarisworks ogara chshz npt-d acked Take charge of your medical conditions now. Order online. Live a healthier and happier life - all from the comfort of your home! Quality Meds we offer: V`ic0-din ES 90 Tab Special. Fedex delivery. http://hclgyt.net.azsw3d.com/?p=8089 Your comfort and convenience is our prime concern. N.o thanks: http://uhbq.j.foresmdb.com/a.html A professor was

You're right, that probably won't have very good performance. What we (unladen-swallow) do is to call getPointerToFunction which gives a function pointer of type (void*)(void*) which we then cast to the appropriate function type and then call from C/C++. That way the C/C++ compiler for your application can codegen the function call once instead having the JIT do it many times. Reid On

While browsing the configure generated llvm/Config/config.h, I'm noticed that the macros: HAVE_FFI_CALL HAVE_FFI_FFI_H HAVE_FFI_H are not defined on OS X (currently 10.6.5). Given that ffi exists on this platform (both headers and lib), is this result intended? Thanks Garrison

Ah, --enable-libffi. Any pointers as why this is not a default check for at least UNIX systems? Does Windows have the equivalent? Thanks in advance Garrison On Dec 14, 2010, at 6:34, Garrison Venn wrote: > While browsing the configure generated llvm/Config/config.h, I'm noticed that > the macros: > > HAVE_FFI_CALL > HAVE_FFI_FFI_H > HAVE_FFI_H > > are not

Hello, I'm new to LLVM and I had a question about it: when we call the JIT::runFunction, since llvm doesn't has a full FFI, there are some cases in which the JIT needs to codegen a stub function to call the function we are interested, my question is: this stub function will remains in the module until when ? What are the most efficient way to remove it from the module and memory ? For a

Hi, I''ve been using FFI with a Ruby 1.9.3 built with MSVC++ and it''s been working well. One thing I''ve run into though is this: ffi_lib :msvcrt But that''s not the runtime I want. But I don''t want to hard code the runtime name either. I realize I could parse it out of RbConfig, but I was hoping for something nicer. Is there a way we could create an