Displaying 16 results from an estimated 16 matches similar to: "[LLVMdev] Seg Fault when creating an execution engine"
2017 Mar 09
2
LLVMGetBitcodeModuleInContext2 problem
Oops, missed initializing some stuff. Added:
LLVMLinkInMCJIT();
LLVMInitializeNativeTarget();
LLVMInitializeNativeAsmPrinter();
LLVMInitializeNativeAsmParser();
Now it crashes in LLVMGetFunctionAddress().
Hmm.
On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote:
> Made it a bit further. Here's the current code:
>
>
2017 Mar 08
2
LLVMGetBitcodeModuleInContext2 problem
Or do you mean I need to load the module into memory before calling
LLVMGetBitcodeModuleInContext2?
> Yes, you need to load the module into memory first.
> LLVMCreateMemoryBufferWithContentsOfFile will do that for you.
Thanks!
On Wed, Mar 8, 2017 at 3:48 PM, Friedman, Eli <efriedma at codeaurora.org>
wrote:
> On 3/8/2017 3:44 PM, Toshiyasu Morita wrote:
>
>
>>
2012 Apr 25
2
[LLVMdev] Crash in JIT
Hello,
[Using LLVM r155315, according to `svn log | head`]
I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this:
; ModuleID = 'MyModule'
target datalayout = "i686-apple-darwin11"
target triple =
2012 Apr 25
0
[LLVMdev] Crash in JIT
Hi David,
I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code.
I think that if you omit that line completely then the target will be inferred from the execution environment. My best
2017 Jan 25
2
mcjit C interface problems
Hi, I'm attempting to use MCJIT with the C interface with llvm-3.9.0, and
it doesn't seem to work. This code is derived from Paul Smith's example
code:
int main(int argc, char const* argv[]) {
LLVMModuleRef mod = LLVMModuleCreateWithName("my_module");
LLVMTypeRef param_types[] = {LLVMInt32Type(), LLVMInt32Type()};
LLVMTypeRef ret_type =
2016 Aug 10
2
crash JIT with AVX intrinsics
Hi all,
I have some old code using the JIT via the LLVM-3.0-C API. I want to
upgrade to newer versions of LLVM. As a simple example I wrote a C program
that creates the following function and calls it:
; ModuleID = 'round-avx.bc'
target triple = "x86_64-pc-linux-gnu"
define void @round(<8 x float>*) {
_L1:
%1 = load <8 x float>* %0
%2 = call <8 x
2009 Aug 23
5
[LLVMdev] [PATCH]: enable multilib build on x86_64-apple-darwin
Current llvm-gcc-4.2 for trunk and the 2.6 release
is unable to build the i386 multilib for the
x86_64-apple-darwin target. The attached patch provides
this support. Can we get this into the 2.6 release
and trunk?
Jack
-------------- next part --------------
Index: gcc/config/i386/t-darwin64
===================================================================
---
2015 Jun 05
2
[LLVMdev] LLVM-ar and openssl
Hi everyone,
I encountered a strange bug when I tried to compile openssl (https://www.openssl.org/) with clang and llvm-ar on a 64-bit OS X.
I changed the openssl makefile to use llvm-ar instead of simply ar.
Openssl will then create two static libraries libssl.a and libcrypto.a.
The problem occurs when it tries to link these two static libraries to the final openssl executable.
I get the
2013 Feb 20
0
[LLVMdev] LLVM Interpreter & QSort
Hi,
I am trying to run an LLVM analysis on a C++ program that calls
qsort(), using the LLVM interpreter (lli --force-interpreter). The code
is the qsort_large.c file in the MiBench benchmark suite. If I comment
the qsort() call, the execution works fine. If I uncomment the qsort()
call, I run into a segmentation fault error as follows:
0 lli 0x0000000000d35c6f
1 lli
2013 Feb 20
0
[LLVMdev] LLVM Interpreter & Qsort
Hi,
I am trying to run an LLVM analysis on a C++ program that calls qsort(),
using the LLVM interpreter (lli --force-interpreter). The code is the
qsort_large.c file in the MiBench benchmark suite. If I comment the qsort()
call, the execution works fine. If I uncomment the qsort() call, I run into
a segmentation fault error as follows:
0 lli 0x0000000000d35c6f
1 lli
2010 Sep 01
2
[Bug 1813] New: Cannot compile on Mac OS X with non-default OpenSSL
https://bugzilla.mindrot.org/show_bug.cgi?id=1813
Summary: Cannot compile on Mac OS X with non-default OpenSSL
Product: Portable OpenSSH
Version: 5.6p1
Platform: All
OS/Version: Mac OS X
Status: NEW
Severity: minor
Priority: P2
Component: Build system
AssignedTo: unassigned-bugs at mindrot.org
2017 Jan 25
2
sshd 7.4p1 with ssl 1.0.2j seg faults, MacOSX 10.12.2/3, clang-800.0.42.1
Never had much trouble building on the Mac until this round.
Trying to build 7.4p1 with openssl 1.0.2j on a MacOSX 10.12.2/3
machine. gcc --version returns clang-800.0.42.1. This is the
latest Xcode.
Builds fine. Upon running sshd, it seg faults with this in the logs:
assertion failed 16C67: libsystem_trace.dynlib+76912
[5BD4ECD4-75CA-38EA-AF5C-B481C15955F8]: 0x0
If I run the tests, it
2009 Aug 31
10
[LLVMdev] 2.6 pre-release1 ready for testing
LLVMers,
2.6 pre-release1 is ready to be tested by the community.
http://llvm.org/prereleases/2.6/
You will notice that we have quite a few pre-compiled binaries (of
both clang and llvm-gcc). We have identified several bugs that will be
fixed in pre-release2, so please search the bug database before filing
a new bug.
If you have time, I'd appreciate anyone who can help test the
2017 Jun 22
2
lld extra program headers
Hello all,
The lld linker appears to generate extra ELF program headers and thus
causes file sizes to be significantly larger than what would get with
ld.gold or ld.bfd.
# readelf -l test.bfd
Elf file type is EXEC (Executable file)
Entry point 0x4000b0
There are 2 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
2015 Jul 10
2
[LLVMdev] DataFlowSanitizer only for Linux
Kostya,
I took a quick stab at patching libFuzzer for Apple, but so far I'm
thinking something else is incorrect. Patch is attached but when I went to
reproduce the examples, the toy example went fine, but with PCRE and
Heartbleed I noticed the coverage statistics were pretty poor, and didn't
find anything. Admittedly I moved onto Heartbleed pretty quickly so PCRE
probably isn't the
2013 Jun 24
1
[LLVMdev] DebugInfo: Missing non-trivially-copyable parameters in SelectionDAG
This is a bit premature to be considered a code review, but given how
unfamiliar I am with SelectionDAG (& that I'm seeing somewhat more
'interesting' results compared to my change to FastISel) I wanted to
get a bit of feedback to see if I was on the right track or had missed
any obvious cases.
I've attached my patch in progress (including a modification to the
existing test