search for: r_x86_64_64

Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with hidden visibility to inform the compiler that symbol references are never resolved at runti...

..._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_frame 0000000000000044 R_X86_64_64 .text+0x0000000000000040 RELOCATION RECORDS FOR [.debug_info]: OFFSET TYPE VALUE 0000000000000006 R_X86_64_32 .debug_abbrev 0000000000000097 R_X86_64_64 .text 0000000...

.... On Mon, Jan 28, 2019 at 7:35 AM Shi, Steven <steven.shi at intel.com<mailto:steven.shi at intel.com>> wrote: Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with hidden visibility to inform the compiler that symbol references are never resolved at runti...

.... On Mon, Jan 28, 2019 at 7:35 AM Shi, Steven <steven.shi at intel.com<mailto:steven.shi at intel.com>> wrote: Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with hidden visibility to inform the compiler that symbol references are never resolved at runti...

...ta .JTab: .quad .L00, .L01, .L02, .L03, .L04, .L05, .L06, .L07 .quad .L08, .L09, .L10, .L11, .L12, .L13, .L14, .L15, .L16 $ gcc -o rodatareloc.s.o -c rodatareloc.s $ lld -o rodatareloc.so -shared rodatareloc.s.o ld: error: rodatareloc.s.o:(.rodata+0x0): can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment defined in rodatareloc.s.o Changing the section from .rodata to .data fixes it, but I guess this should be supported also for .rodata. Should I open a bug? Best regards, Martin -------------- next part -------------- A non-text attachment was scrubbed......

...nMemoryManager 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 _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.c...

Rafael Avila de Espindola wrote: >> $ gcc -o rodatareloc.s.o -c rodatareloc.s >> $ lld -o rodatareloc.so -shared rodatareloc.s.o >> >> ld: error: rodatareloc.s.o:(.rodata+0x0): can't create dynamic >> relocation >> R_X86_64_64 against local symbol in readonly segment defined in >> rodatareloc.s.o >> >> >> Changing the section from .rodata to .data fixes it, but I guess this >> should be supported also for .rodata. Should I open a bug? > > I think this is just a difference in defaults....

...static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, const char *symname) @@ -895,8 +905,12 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, * the relocations are processed. * Make sure that the offset will fit. */ - if (r_type != R_X86_64_64 && (int32_t)offset != (int64_t)offset) + if (r_type != R_X86_64_64 && + (int32_t)offset != (int64_t)offset) { + if (is_in_xenpvh_assembly(offset)) + break; die("Relocation offset doesn't fit in 32 bits\n"); + } if (r_type == R_X86_64_64) add_re...

...nMemoryManager* 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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/1cc9b0e1/attachmen...

...ation can trigger this as well) > * a relocation referencing an undefined symbol in a non-SHF_ALLOC section > > We always respect the addend in a relocation entry for an absolute/PC- > relative (I can use "most" here) > relocation (R_ARM_THM_PC8, R_AARCH64_ADR_PREL_PG_HI21, R_X86_64_64, > local exec TLS relocation types, ...) > Ignoring the addend (using -2 everywhere) will break this consistency. > > The relocated code may do pointer subtraction which would work if addends > were > respected, but will break using -2 everywhere. >I suspect David meant "...

...4 spec, you'll note that it defines things like: A = the addend field of the relocation B = base address which the shared object has been loaded into P = address of the storage being relocated S = value of the symbol whose index resides in the relocation entry and then the relocations are R_X86_64_64: S + A R_X86_64_PC32: S + A - P so my thinking was that a client class could define functions that provide values for A,B,P,S,etc., and then we break down visiting a relocations down to calls to those functions. Those which really can't be implemented generically (IRELATIVE?) should be pure v...

...t;In DWARF4 for .debug_str is referenced from .debug_info, .debug_type using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's 64bit unsigned. So in relocation section for some .debug_info section we will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, or R_X86_64_64, depending on DWARF format. > >A situation we might have is that an input .debug_info section is DWARF32 so it gets ordered apropriatly within output .debug_info section, but the input .debug_str section can be put in the output .debug_str section that is above 4GB. In which case we still hit...

...; > section > >> > > > > >> > > > We always respect the addend in a relocation entry for an absolute/PC- > >> > > > relative (I can use "most" here) > >> > > > relocation (R_ARM_THM_PC8, R_AARCH64_ADR_PREL_PG_HI21, R_X86_64_64, > >> > > > local exec TLS relocation types, ...) > >> > > > Ignoring the addend (using -2 everywhere) will break this consistency. > >> > > > > >> > > > The relocated code may do pointer subtraction which would work if > &g...

On 28.04.23 11:50, Hou Wenlong wrote: > Similar to the alternative patching, use relative reference for original > instruction rather than absolute one, which saves 8 bytes for one entry > on x86_64. And it could generate R_X86_64_PC32 relocation instead of > R_X86_64_64 relocation, which also reduces relocation metadata on > relocatable builds. And the alignment could be hard coded to be 4 now. > > Signed-off-by: Hou Wenlong <houwenlong.hwl at antgroup.com> > Cc: Thomas Garnier <thgarnie at chromium.org> > Cc: Lai Jiangshan <jiangsha...

...; > > > > >> >> > > > We always respect the addend in a relocation entry for an absolute/PC- > >> >> > > > relative (I can use "most" here) > >> >> > > > relocation (R_ARM_THM_PC8, R_AARCH64_ADR_PREL_PG_HI21, R_X86_64_64, > >> >> > > > local exec TLS relocation types, ...) > >> >> > > > Ignoring the addend (using -2 everywhere) will break this consistency. > >> >> > > > > >> >> > > > The relocated code may do pointer sub...

...y --gc-sections implementation can trigger this as well) * a relocation referencing an undefined symbol in a non-SHF_ALLOC section We always respect the addend in a relocation entry for an absolute/PC-relative (I can use "most" here) relocation (R_ARM_THM_PC8, R_AARCH64_ADR_PREL_PG_HI21, R_X86_64_64, local exec TLS relocation types, ...) Ignoring the addend (using -2 everywhere) will break this consistency. The relocated code may do pointer subtraction which would work if addends were respected, but will break using -2 everywhere. The relocated code can be allocatable or not. Non-allocatable...

...efined symbol in a non-SHF_ALLOC > > section > > > > > > > > We always respect the addend in a relocation entry for an absolute/PC- > > > > relative (I can use "most" here) > > > > relocation (R_ARM_THM_PC8, R_AARCH64_ADR_PREL_PG_HI21, R_X86_64_64, > > > > local exec TLS relocation types, ...) > > > > Ignoring the addend (using -2 everywhere) will break this consistency. > > > > > > > > The relocated code may do pointer subtraction which would work if > > addends > > > > were...

...ug_str is referenced from .debug_info, .debug_type > using DW_FORM_strp. For DWARF32 it's 32bit unsigned, for DWARF64 it's > 64bit unsigned. So in relocation section for some .debug_info section we > will have a relocation entry to patch up DW_FORM_strp. Either R_X86_64_32, > or R_X86_64_64, depending on DWARF format. > > > >A situation we might have is that an input .debug_info section is DWARF32 > so it gets ordered apropriatly within output .debug_info section, but the > input .debug_str section can be put in the output .debug_str section that > is above 4GB. I...

.../llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer the relocation based approach: if a .debug_* has an 64-bit absolute relocation type (e.g. R_X86_64_64). In LLD, for an input section, we don't know its associated SHT_REL[A] section. So when adding an orphan section we would have another loop iterating over inputSections. We can reuse the dependentSections to have this piece of information (generalizing the existing special case for -r/--emit...

...naries. @Fangrui Song<mailto:maskray at google.com> That's a good point with relocations. Although is it always a guarantee a first one will be representative of entire relocation record? For debug_info even with DWARF32 there can be 64bit relocations. 0000000000000c57 0000001800000001 R_X86_64_64 0000000000000000 .text._"some_mangeled_name" + 0 On one hand since this is only applicable for when DWARF64 is used, special option would be the way to go. Although the user will need to be aware of yet another LLD option. Maybe an error when relocations overflow occur can be...