search for: r_x86_64_32

ELF module of type ET_REL (Relocable module), generated by LLVM, always has some R_X86_64_32 in debug information sections. This happens with Reloc models Default,Static,PIC_ and with CodeModel set to Large. What is the way to prevent R_X86_64_32 ELF from ever appearing in ELF? Yuri

On 04/26/2013 19:50, Jiong Wang wrote: > > > why do you want to prevent R_X86_64_32 generation? for 32bit dwarf, > I think generation of R_X86_64_32 is reasonable. > > you can check http://dwarfstd.org/doc/DWARF4.pdf. Because R_X86_64_32 elements are 4-byte addresses and can't be relocated for the 64-bit address space over 32-bit limit. Dwarf2 actually allows f...

On 04/27/2013 08:07 AM, Yuri wrote: > ELF module of type ET_REL (Relocable module), generated by LLVM, > always has some R_X86_64_32 in debug information sections. > This happens with Reloc models Default,Static,PIC_ and with CodeModel > set to Large. > > What is the way to prevent R_X86_64_32 ELF from ever appearing in ELF? Hi Yuri, why do you want to prevent R_X86_64_32 generation? for 32bit dwarf, I think g...

...o large to fit in 32-bit DWARF tables. Keith -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Yuri Sent: 27 April 2013 04:02 To: Jiong Wang Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] How to prevent LLVM from emitting R_X86_64_32 ELF relocations? On 04/26/2013 19:50, Jiong Wang wrote: > > > why do you want to prevent R_X86_64_32 generation? for 32bit dwarf, > I think generation of R_X86_64_32 is reasonable. > > you can check http://dwarfstd.org/doc/DWARF4.pdf. Because R_X86_64_32 elements are 4-byt...

On 04/29/2013 09:12, Keith Walker wrote: > You only need to go to 64-bit DWARF when your debugging information becomes > too large to fit in 32-bit DWARF tables. I am not sure if this is true. Currently R_X86_64_32 EL relocations are issued for DWARF-32 debug info sections. This is because the size of address in DWARF-32 is only 32-bits, according to the above mentioned specification. Such relocations can't be resolved (without overflow) when the base address is 64-bit and higher than 4GB threshold....

..._cntrlify.o g_fontdb.o g_her_glyph.o xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o` ../extra/tre/libtre.a -L"../../lib" -lRblas -lgfortran -lm -lquadmath -lreadline -lpcre -llzma -lbz2 -lz -lrt -ldl -lm -licuuc -licui18n /usr/bin/x86_64-linux-gnu-ld: ../appl/dchdc.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: ../appl/dpbfa.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: ../appl/dpbsl.o: relocation R...

...s I would have to ask you why as they are not normally loaded into target memory? Keith -----Original Message----- From: Yuri [mailto:yuri at rawbw.com] Sent: 29 April 2013 21:30 To: Keith Walker Cc: Jiong Wang; LLVM Developers Mailing List Subject: Re: [LLVMdev] How to prevent LLVM from emitting R_X86_64_32 ELF relocations? On 04/29/2013 09:12, Keith Walker wrote: > You only need to go to 64-bit DWARF when your debugging information becomes > too large to fit in 32-bit DWARF tables. I am not sure if this is true. Currently R_X86_64_32 EL relocations are issued for DWARF-32 debug info sections....

...r DWARF-32 debug info. So having DWARF-32 either forces abandoning the simple monolithic mount of the ELF at arbitrary address, and treating debug info separately, or just placing the whole ELF into the lowest 4G. So, in case when it is preferable to load the whole ELF together monolithically, R_X86_64_32 entries stand in the way. I am not sure why llvm has to use DWARF-32 by default on x86_64 architectures. Yuri

...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 .text 0000000000000040 R_X86_64_32 .debug_fra...

...the following error: [AR] bin-x86_64-efi/blib.a ar: creating bin-x86_64-efi/blib.a [HOSTCC] util/elf2efi64 [VERSION] bin-x86_64-efi/version.ipxe.efi.o [LD] bin-x86_64-efi/ipxe.efi.tmp bin-x86_64-efi/blib.a(librm.o): In function `pm_esp': (.data.pm_esp+0x0): relocation truncated to fit: R_X86_64_32 against symbol `_estack' defined in .stack section in bin-x86_64-efi/blib.a(stack.o) bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': (.text16.real_to_prot+0x1): relocation truncated to fit: R_X86_64_PC16 against symbol `enable_a20' defined in .text16.early section in bin-x86...

v1 was here: https://www.redhat.com/archives/libguestfs/2017-November/msg00068.html v1 -> v2: - Use a configure-time test. Rich.

...cmplx.lo g77 -fPIC -g -O2 -c cmplxblas.f -o cmplxblas.lo gcc -shared -L/usr/local/lib64 -o libRlapack.so dlamc.lo dlapack0.lo dlapack1.lo dlapack2.lo dlapack3.lo cmplx.lo cmplxblas.lo -lg2c -lm -lgcc_s /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/libg2c.a(s_cat.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.4/libg2c.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libRlapack.so] Error 1 I am confused by the error message &...

...g like this (on x86-64): 0000000000000000 <.debug_info>: 0: aa stos %al,%es:(%rdi) 1: 00 00 add %al,(%rax) 3: 00 02 add %al,(%rdx) 5: 00 00 add %al,(%rax) 6: R_X86_64_32 .debug_abbrev 7: 00 00 add %al,(%rax) 9: 00 08 add %cl,(%rax) b: 01 00 add %eax,(%rax) c: R_X86_64_32 .debug_line Note the R_X86_64_32 relocations. At link time, these relocations will be...

...x86_64-efi/blib.a > ar: creating bin-x86_64-efi/blib.a > [HOSTCC] util/elf2efi64 > [VERSION] bin-x86_64-efi/version.ipxe.efi.o > [LD] bin-x86_64-efi/ipxe.efi.tmp > bin-x86_64-efi/blib.a(librm.o): In function `pm_esp': > (.data.pm_esp+0x0): relocation truncated to fit: R_X86_64_32 against symbol > `_estack' defined in .stack section in bin-x86_64-efi/blib.a(stack.o) > bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': > (.text16.real_to_prot+0x1): relocation truncated to fit: R_X86_64_PC16 > against symbol `enable_a20' defined in .text16.earl...

...t; ar: creating bin-x86_64-efi/blib.a >> [HOSTCC] util/elf2efi64 >> [VERSION] bin-x86_64-efi/version.ipxe.efi.o >> [LD] bin-x86_64-efi/ipxe.efi.tmp >> bin-x86_64-efi/blib.a(librm.o): In function `pm_esp': >> (.data.pm_esp+0x0): relocation truncated to fit: R_X86_64_32 against >> symbol >> `_estack' defined in .stack section in bin-x86_64-efi/blib.a(stack.o) >> bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': >> (.text16.real_to_prot+0x1): relocation truncated to fit: R_X86_64_PC16 >> against symbol `enable_a20'...

Not totally sure about this. Perhaps we should make ./configure look for the right asmrun library? Or make it user-configurable? Rich.

In OCaml 4.06 we need to link to daemon to libasmrun_pic.a (the OCaml runtime linked with -fPIC). Otherwise you will see many errors like this: /usr/bin/ld: /usr/lib64/ocaml/libasmrun.a(startup_aux.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib64/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32S against symbol `caml_data_segments' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld:...

...4.1. I get the following error: g++ -shared -L/usr/local/lib64 -o gmp.so biginteger.o biginteger_operator.o bigintegerR.o bigrational.o bigrational_operator.o bigrationalR.o factor.o -L/usr/local/lib/ -lgmp /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a(functexcept.o): relocation R_X86_64_32 against `std::bad_exception::~bad_exception()' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.a: could not read symbols: Bad value However, I have found that if I run "R CMD SHLIB" twice in the src/ directory, once t...

...ils building lapack.so gcc -shared -L/usr/local/lib64 -o lapack.so Lapack.lo -llapack -lblas -lg2c -lm -lgcc_s /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/liblapack.a(dgecon.i): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/liblapack.a: could not read symbols: Bad value The 'recompile with -fPIC' is bullsh*t. The problem is that is is looking in /usr/...

> /usr/bin/ld: /usr/lib/mysql/libmysqlclient.a(libmysql.o): relocation > R_X86_64_32 can not be used when making a shared object; recompile > with -fPIC > /usr/lib/mysql/libmysqlclient.a: could not read symbols: Bad value > collect2: ld returned 1 exit status Never seen that before. What OS are you using? What version of MySQL? > Dec 29 12:58:22 WARNING[22260]: No...