From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA061C35242 for ; Sat, 8 Feb 2020 18:29:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AFA2A24654 for ; Sat, 8 Feb 2020 18:29:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727542AbgBHS3c (ORCPT ); Sat, 8 Feb 2020 13:29:32 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:33392 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727465AbgBHS3b (ORCPT ); Sat, 8 Feb 2020 13:29:31 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1j0UrB-0003Zp-Qi; Sat, 08 Feb 2020 18:29:29 +0000 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1j0UrB-000CIb-9S; Sat, 08 Feb 2020 18:29:29 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Linus Torvalds" , "H.J. Lu" , "Woody Suwalski" Date: Sat, 08 Feb 2020 18:19:02 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 003/148] x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.82-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: "H.J. Lu" commit b21ebf2fb4cde1618915a97cc773e287ff49173e upstream. On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu Signed-off-by: Linus Torvalds [Woody Suwalski: Backported to 3.16] Signed-off-by: Woody Suwalski Signed-off-by: Ben Hutchings --- --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -180,6 +180,7 @@ int apply_relocate_add(Elf64_Shdr *sechd goto overflow; break; case R_X86_64_PC32: + case R_X86_64_PLT32: val -= (u64)loc; *(u32 *)loc = val; #if 0 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -763,6 +763,7 @@ static int do_reloc64(struct section *se switch (r_type) { case R_X86_64_NONE: case R_X86_64_PC32: + case R_X86_64_PLT32: /* * NONE can be ignored and PC relative relocations don't * need to be adjusted.