search for: r_x86_64_pc32

...n 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'' /root/randy/vtd-stage/xen/arch/x86/built_in.o: In function `relinquish_memory'': /root/randy/vtd-stage/xen/arch/x86/domain.c:1705: undefined reference to `__bitop_bad_size'' /root/randy/vtd-stage/xen/arch/x86/domain.c:1705: reloca...

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

...etype=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 /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273. I noticed that R_X86_64_PC32 relocations are used only within .eh_frame section. Why aren't R_X86_64_64 relocations used in that case? Is there any working solution of this problem? Thank you in advance. -- Best regards, Alexey Zasenko -------------- next part -------------- An HTML attachment was scrubbed... URL: <h...

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 R_386...

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?

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 c...

...bjdump -r skeleton.o skeleton.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000019 R_X86_64_32S .rodata.str1.1+0x0000000000000015 0000000000000024 R_X86_64_32S .rodata.str1.1+0x000000000000002b 000000000000002b R_X86_64_PC32 uprintf-0x0000000000000004 [...] clang10: $ objdump -r skeleton.o skeleton.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000017 R_X86_64_32S .rodata.str1.1+0x000000000000002b 0000000000000020 R_X86_64_32S...

The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. #include <stdio.h> int main() { fputs("hi\n", stdout); } The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions and thus need PLT entries. The correct behavior is to treat this as a R_X86_64_GOTPCREL relocation. As this is what both gnu-ld and gold do. To handle...

> You used -noinhibit-exec to ignore the diagnostic, which is usually a bad thing. I certainly agree with that. The point I was trying to make in my original email is that, specifically for kernel objects, this diagnostic is incorrect. R_X86_64_PC32 can be used safely against the symbol foo in that specific context, and should be possible without ignoring diagnostics. I wondered if there should be a way for the user to share that notion with the linker (my earlier "-mcmodel=kernel for the linker" comments). But I understand your poi...

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 32-bit relocation can't b...

...lowing code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >> >> #include <stdio.h> >> >> int main() { >> fputs("hi\n", stdout); >> } >> >> The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions and thus need PLT entries. The correct behavior is to treat this as a R_X86_64_GOTPCREL relocation. As this is what both gnu-ld and gold do. >> &...

...l.com> wrote: > The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. > > #include <stdio.h> > > int main() { > fputs("hi\n", stdout); > } > > The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions and thus need PLT entries. The correct behavior is to treat this as a R_X86_64_GOTPCREL relocation. As this is what both gnu-ld and gold do. > >...

...info and dumped the relocation entries, then I commented out the top block so that EmitLabelDifference was always called. Original: objdump -r directsymbol.o directsymbol.o: file format elf64-x86-64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 000000000000005a R_X86_64_PC32 atoi-0x0000000000000004 0000000000000066 R_X86_64_32 .rodata.str1.1 000000000000006f R_X86_64_PC32 printf-0x0000000000000004 RELOCATION RECORDS FOR [.debug_frame]: OFFSET TYPE VALUE 0000000000000018 R_X86_64_32 .debug_frame 000000000000001c R_X86_64_64...

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 IRBuilder::CreateAlloca appears in a conditional block). Perhaps the issue can be fixed by using indirect call via 64-bit register or replicating service routines inside jitted block. Is it known issue? Repro is ava...

...0 callq 2b <_Z4funcj+0x2b> As for aarch64, x86_64 object shows some relocation in group sections: Relocation section '.rela.text' at offset 0xb48 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000005 003200000002 R_X86_64_PC32 0000000000000000 _ZNSt9exceptionD2Ev - 4 00000000000e 003700000002 R_X86_64_PC32 0000000000000000 _ZdlPv - 4 That should me meant only for the group section text, not the default text segment. On 06-05-2015 18:18, Shankar Easwaran wrote: > Does this test pass on X86_64 ? Groups are r...

...ow when make I see ... openbsd-compat//libopenbsd-compat.a(xcrypt.o): In function `xcrypt': /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83: undefined reference to `crypt' /cygdrive/c/openssh-portable-master/openbsd-compat/xcrypt.c:83:(.text+0x5): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `crypt' I tried to do ./configure --without-openssl --with-ldflags=-lcrypt but configure fails with checking compiler and flags for sanity... no configure: error: *** compiler cannot create working executables, check config.log *** Here is my config.log https://ww...

...pletes normally without errors or warnings make #### make fails, always with lines like: /usr/bin/x86_64-linux-gnu-ld: ../appl/dtrsl.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: attrib.o: relocation R_X86_64_PC32 against symbol `R_NilValue' can not be used when making a shared object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: final link failed: Bad value collect2: error: ld returned 1 exit status Makefile:177: recipe for target 'libR.so' failed make[3]: *** [libR.so] Error 1 make[3]: Le...

I want to make a shared object from Fortran code to be loaded with dyn.load(), but have the following messages: # g77 -c kerimp1.f # R CMD SHLIB kerimp1.o gcc -shared -L/usr/local/lib64 -o kerimp1.so kerimp1.o -L/usr/lib64/R/lib -lR /usr/bin/ld: kerimp1.o: relocation R_X86_64_PC32 against `qweight_' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [kerimp1.so] Error 1 I have not encountered any problem with my old 32bit machine. I now run Redhat Enterprise 4.3 on De...

...that will be flexible enough to use the llvm suite of compilers to build shared libraries for talking to USB peripherals. The problem that I am having is that while I am able to build a shared library using llvm-gcc , the llvm-g++ compiler is giving me error messages saying " relocation R_X86_64_PC32 against undefined symbol `__morestack' can not be used when making a shared object; recompile with -fPIC Here's my configuration on my local machine: cat /etc/issue Ubuntu-12.04 uname -a Linux localhost 3.2.0-48-generic #74-Ubuntu SMP Thu Jun 6 19:43:26 UTC 2013 x86_64 x86_64 x86_64 G...

...find the small code model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL type relocation entries in my firmware image, which not happen in the clang LTO build. I wish I could enforce the clang normal build not to use the R_X86_64_GOTPCREL relocation type but to use R_X86_64_PC32 or R_X86_64_PLT32 instead. How could I do it? Does it reproduce with clang trunk? Cheers, Rafael