devel@edk2.groups.io | [PATCH] BaseTools X64: fold PLT relocations into simple relative references

Home Messages Hashtags Subgroups Calendar

Date Date 1 - 7 of 7

[PATCH] BaseTools X64: fold PLT relocations into simple relative references

Ard Biesheuvel #471 For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbols references are never resolved at runtime, which removes the need for PLTs and GOTs. However, in some cases GCC has been reported to still emit PLT based relocations, which we need to handle in the ELF to PE/COFF perform by GenFw. Unlike GOT based relocations, which are non-trivial to handle since the indirections in the code can not be fixed up easily (although relocation types exist for X64 that annotate relocation targets as suitable for relaxation), PLT relocations simply point to jump targets, and we can relax such relocations by resolving them using the symbol directly rather than via a PLT entry that does nothing more than tail call the function we already know it is going to call (since all symbol references are resolved in the same module). So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation. Suggested-by: Steven Shi <steven.shi@...> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...> --- BaseTools/Source/C/GenFw/Elf64Convert.c \| 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index 944c94b8f8b4..7cbff0df0996 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -785,6 +785,17 @@ WriteSections64 ( (INT32 )Targ = (INT32)((INT64)((INT32 )Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]); VerboseMsg ("Relocation: 0x%08X", (UINT32)Targ); break; + + case R_X86_64_PLT32: + // + // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is + // possible since we know all code symbol references resolve to + // definitions in the same module (UEFI has no shared libraries), + // and so there is never a reason to jump via a PLT entry, + // allowing us to resolve the reference using the symbol directly. + // + VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ..."); + /* fall through */ case R_X86_64_PC32: // // Relative relocation: Symbol - Ip + Addend -- 2.7.4
More All Messages By This Member
Shi, Steven <steven.shi@...> #472 Hi Ard, I don't see you add below code for case R_X86_64_PLT32. Is it right? (UINT32 )Targ = (UINT32) ((UINT32 )Targ + (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr) - (SecOffset - SecShdr->sh_addr)); Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 toggle quoted message Show quoted text -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@...] Sent: Thursday, August 04, 2016 4:46 PM To: Shi, Steven <steven.shi@...>; Zhu, Yonghong <yonghong.zhu@...>; Gao, Liming <liming.gao@...>; Justen, Jordan L <jordan.l.justen@...>; edk2-devel@... Cc: mischief@...; Ard Biesheuvel <ard.biesheuvel@...> Subject: [PATCH] BaseTools X64: fold PLT relocations into simple relative references For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbols references are never resolved at runtime, which removes the need for PLTs and GOTs. However, in some cases GCC has been reported to still emit PLT based relocations, which we need to handle in the ELF to PE/COFF perform by GenFw. Unlike GOT based relocations, which are non-trivial to handle since the indirections in the code can not be fixed up easily (although relocation types exist for X64 that annotate relocation targets as suitable for relaxation), PLT relocations simply point to jump targets, and we can relax such relocations by resolving them using the symbol directly rather than via a PLT entry that does nothing more than tail call the function we already know it is going to call (since all symbol references are resolved in the same module). So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation. Suggested-by: Steven Shi <steven.shi@...> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...> --- BaseTools/Source/C/GenFw/Elf64Convert.c \| 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index 944c94b8f8b4..7cbff0df0996 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -785,6 +785,17 @@ WriteSections64 ( (INT32 )Targ = (INT32)((INT64)((INT32 )Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]); VerboseMsg ("Relocation: 0x%08X", (UINT32)Targ); break; + + case R_X86_64_PLT32: + // + // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is + // possible since we know all code symbol references resolve to + // definitions in the same module (UEFI has no shared libraries), + // and so there is never a reason to jump via a PLT entry, + // allowing us to resolve the reference using the symbol directly. + // + VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ..."); + /* fall through */ case R_X86_64_PC32: // // Relative relocation: Symbol - Ip + Addend -- 2.7.4
More
Ard Biesheuvel #473 On 4 August 2016 at 10:54, Shi, Steven <steven.shi@...> wrote: Hi Ard, I don't see you add below code for case R_X86_64_PLT32. Is it right? (UINT32 )Targ = (UINT32) ((UINT32 )Targ + (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr) - (SecOffset - SecShdr->sh_addr)); Isn't it identical to the code for R_X86_64_PC32?
More All Messages By This Member
Shi, Steven <steven.shi@...> #474 OK, it is. But it is a bit not very clear. Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 toggle quoted message Show quoted text -----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@...] Sent: Thursday, August 04, 2016 4:55 PM To: Shi, Steven <steven.shi@...> Cc: Zhu, Yonghong <yonghong.zhu@...>; Gao, Liming <liming.gao@...>; Justen, Jordan L <jordan.l.justen@...>; edk2-devel@...; mischief@... Subject: Re: [PATCH] BaseTools X64: fold PLT relocations into simple relative references On 4 August 2016 at 10:54, Shi, Steven <steven.shi@...<mailto:steven.shi@...>> wrote: Hi Ard, I don't see you add below code for case R_X86_64_PLT32. Is it right? (UINT32 )Targ = (UINT32) ((UINT32 )Targ + (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr) - (SecOffset - SecShdr->sh_addr)); Isn't it identical to the code for R_X86_64_PC32?
More
Ard Biesheuvel #475 On 4 August 2016 at 10:58, Shi, Steven <steven.shi@...> wrote: OK, it is. But it is a bit not very clear. Did you read the elaborate comment block explaining that (and why) it is appropriate to treat R_X86_64_PLT32 as a R_X86_64_PC32 relocation? This is not generally true, but it is true for UEFI since we don't support shared libraries. So I think it is incorrect to simply duplicate the code for R_X86_64_PC32 without mentioning that, and suggesting that the PLT relocation receive some kind of treatment that is different. Thanks, Ard.
More All Messages By This Member
Nicolas Owens <mischief@...> #484 ard, i think you need to have R_X86_64_PLT32 case in WriteRelocations64. without that, i still hit the invalid relocation message. toggle quoted message Show quoted text On 08/04/2016 01:45 AM, Ard Biesheuvel wrote: For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbols references are never resolved at runtime, which removes the need for PLTs and GOTs. However, in some cases GCC has been reported to still emit PLT based relocations, which we need to handle in the ELF to PE/COFF perform by GenFw. Unlike GOT based relocations, which are non-trivial to handle since the indirections in the code can not be fixed up easily (although relocation types exist for X64 that annotate relocation targets as suitable for relaxation), PLT relocations simply point to jump targets, and we can relax such relocations by resolving them using the symbol directly rather than via a PLT entry that does nothing more than tail call the function we already know it is going to call (since all symbol references are resolved in the same module). So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation. Suggested-by: Steven Shi <steven.shi@...> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...> --- BaseTools/Source/C/GenFw/Elf64Convert.c \| 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index 944c94b8f8b4..7cbff0df0996 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -785,6 +785,17 @@ WriteSections64 ( (INT32 )Targ = (INT32)((INT64)((INT32 )Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]); VerboseMsg ("Relocation: 0x%08X", (UINT32)Targ); break; + + case R_X86_64_PLT32: + // + // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is + // possible since we know all code symbol references resolve to + // definitions in the same module (UEFI has no shared libraries), + // and so there is never a reason to jump via a PLT entry, + // allowing us to resolve the reference using the symbol directly. + // + VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ..."); + /* fall through */ case R_X86_64_PC32: // // Relative relocation: Symbol - Ip + Addend
More
Ard Biesheuvel #485 On 4 aug. 2016, at 21:03, Nicolas Owens <mischief@...> wrote: ard, i think you need to have R_X86_64_PLT32 case in WriteRelocations64. without that, i still hit the invalid relocation message. Good point. I will send out a v2 tomorrow On 08/04/2016 01:45 AM, Ard Biesheuvel wrote: For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbols references are never resolved at runtime, which removes the need for PLTs and GOTs. However, in some cases GCC has been reported to still emit PLT based relocations, which we need to handle in the ELF to PE/COFF perform by GenFw. Unlike GOT based relocations, which are non-trivial to handle since the indirections in the code can not be fixed up easily (although relocation types exist for X64 that annotate relocation targets as suitable for relaxation), PLT relocations simply point to jump targets, and we can relax such relocations by resolving them using the symbol directly rather than via a PLT entry that does nothing more than tail call the function we already know it is going to call (since all symbol references are resolved in the same module). So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation. Suggested-by: Steven Shi <steven.shi@...> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...> --- BaseTools/Source/C/GenFw/Elf64Convert.c \| 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c index 944c94b8f8b4..7cbff0df0996 100644 --- a/BaseTools/Source/C/GenFw/Elf64Convert.c +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c @@ -785,6 +785,17 @@ WriteSections64 ( (INT32 )Targ = (INT32)((INT64)((INT32 )Targ) - SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]); VerboseMsg ("Relocation: 0x%08X", (UINT32)Targ); break; + + case R_X86_64_PLT32: + // + // Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is + // possible since we know all code symbol references resolve to + // definitions in the same module (UEFI has no shared libraries), + // and so there is never a reason to jump via a PLT entry, + // allowing us to resolve the reference using the symbol directly. + // + VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ..."); + /* fall through */ case R_X86_64_PC32: // // Relative relocation: Symbol - Ip + Addend
More All Messages By This Member

1 - 7 of 7

1

Previous Topic Next Topic

Home Hashtags Subgroups Calendar About Features Pricing Updates Terms Help Twitter