similar to: [LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation

I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually

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>

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 extracted. > > I've tried llvm-extract tool but it

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, 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

linux fedora f9 x86_64 llvm-2.4 I tried building a bunch of my python modules (which compile to shared libraries) using llvm-c++ instead of gnu c++. When the program runs, I see these messages: python: Symbol `__gxx_personality_v0' causes overflow in R_X86_64_PC32 relocation Ideas?

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

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)

Hi, I've tracked down what I believe is a bug in lld's relocation processing for R_X86_64_PC32 REL relocations. I'm producing the object file in a slightly unusual way: I'm using objcopy on a relocatable i386 ELF object file to convert it to x86_64 which transforms a R_386_PC32 into a R_X86_64_PC32. Steps to reproduce: 1. Assemble the attached bug.asm using nasm and note the

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, R_X86_64_PC32 relocations are used for the sections .gcc_except_table and .eh_frame related to exception processing. I am not sure where is general documentation on relocation types, including R_X86_64_PC32. Looks like it's nowhere to be found on the web. But 32-bit relocation can't be used in 64-bit code since it

On 07/08/2011 01:25 PM, Yuri wrote: > ELF that MCJIT writes on x86_64 has relocations in it. Particularly, > R_X86_64_PC32 relocations are used for the sections .gcc_except_table > and .eh_frame related to exception processing. > I am not sure where is general documentation on relocation types, > including R_X86_64_PC32. Looks like it's nowhere to be found on the web. > But

Hi, Attempting to use LLVM in jitting mode for AMD64, we met a problem. When the jitted routine needs a big stack frame (> 1 page), the system attempts to call __chkstk to probe the stack. This attempt results in assertion in RuntimeDyldELF::resolveX86_64Relocation(), case ELF::R_X86_64_PC32, because the RealOffset does not fit in 32 bits. Same happens with __alloca (when

Currently llvm-dwarfdump isn't very useful on ELF .o files because it doesn't apply relocations. nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[ 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk 163034)") 0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang version 3.2 (trunk

Hi Lang, thank You very much. I've used Your code and the creating of the object file works. I think the problem is after creating the object file. When I link the object file with ld I get an executable, which is working right. After changing the clang and llvm libraries from the package control version (.deb) to a own compiled version with debug options, I get an assert() fault. In void

Hello, I am encountering a linking failure when using Control Flow Integrity while building a shared library. It looks like the wrong relocation type is being emitted for functions referenced via the PLT. I am using clang 3.9. The error message I get is: /usr/bin/ld.gold: error: /tmp/lto-llvm-df723d.o: requires dynamic R_X86_64_PC32 reloc against 'free' which may overflow at runtime;

I was looking into the AsmPrinter and the method EmitSectionOffset which contains this code: -------------------------------------------------------------------------------- // If the section in question will end up with an address of 0 anyway, we can // just emit an absolute reference to save a relocation. if (Section.isBaseAddressKnownZero()) { OutStreamer.EmitSymbolValue(Label, 4,

Compilation failure on c/s 17194 is as follows: /root/randy/vtd-stage/xen/common/built_in.o: In function `guest_remove_page'': /root/randy/vtd-stage/xen/common/memory.c:172: undefined reference to `__bitop_bad_size'' /root/randy/vtd-stage/xen/common/memory.c:172: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__bitop_bad_size''

Hi, Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the header files included for different architectures like RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the connection of these files for relocation and linking as the linking and relocation for diff architecture is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp and it doesn't use any function from these

Hello! Is anyone aware why CentOS-7-x86_64-GenericCloud.raw has such unusual format ? root at test-srv:~# wget http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.raw --2016-03-21 13:16:31-- http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.raw Resolving cloud.centos.org (cloud.centos.org)... 162.252.80.138 Connecting to cloud.centos.org