search for: zasenka

...ly does mean that the sections in question got their addresses in different ways. Can you reproduce the problem using lli or llvm-rtdyld? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames Sent: Monday, May 26, 2014 11:33 AM To: Aliaksei Zasenka; LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation I ran into a similar error a while back and it turned out to be user error on my part. I had relocated some of the sections in the object file, but not others. As a result, I'd ended up with one...

On 10/27/16 11:18 AM, Aliaksei Zasenka via llvm-dev wrote: > Hi all, > Can anyone give me advice about an appropriate way for extracting > number of functions from module recursively (starting from entry > point). Actually it may be more than one entry point so all dependent > functions and global values must be extrac...

Hi llvm-community, I use llc (3.4-final) to generate object file: *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o* then I load it with *RuntimeDyld + SectionMemoryManager* in my app. I faced the problem described in 15356 <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion fails at

Hi all, Is it planned to add support of rotations to IR? Thanks, Aleksey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151119/c897b935/attachment.html>

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving

Hi all, Can anyone give me advice about an appropriate way for extracting number of functions from module recursively (starting from entry point). Actually it may be more than one entry point so all dependent functions and global values must be extracted. I've tried llvm-extract tool but it can't do work recursively. Maybe it would be good to write some Call Graph pass or something. Any

Hi all, Need your help. I added some debug information to my code according to Kaleidoscope-9 sample and got stuck with a GDB error: (gdb) info functions > invalid dwarf2 offset 1849950870 > My module is a DLL built with llc+ld toolchain. Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following:

Hi all, Consider the following example: define void @fn(i8* %buf) #0 { entry: %arrayidx = getelementptr i8* %buf, i64 18 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %arrayidx, i8* %buf, i64 18, i32 1, i1 false) %arrayidx1 = getelementptr i8* %buf, i64 18 store i8 1, i8* %arrayidx1, align 1 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %buf, i8* %arrayidx, i64 18, i32 1, i1 false)