Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp867241pxb; Fri, 22 Jan 2021 00:54:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJzjteg40b6HPJM4nEWNjXLspDQ2FOdkZnHyFCKWKA/NSpzACAAlkNudeQDRtqfyp1my8tNC X-Received: by 2002:a17:907:160f:: with SMTP id hb15mr2296178ejc.536.1611305668232; Fri, 22 Jan 2021 00:54:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611305668; cv=none; d=google.com; s=arc-20160816; b=vvQsKV5+ZQWNtqlowcT9Dvg0UdyIHjnY6G6/qq0kYSMZ62UjROqzzcX9bp+SGbzIzj IPAFe2ymgfbnf+AIC6DlryRz3/PePK+zn7zm72Ia+bRsW2mWwiwm5DysXIiyh8JNRtsU WpGcQtNsUWCN/B78gZjw7VJF22aenAWR3k+Lketp5aHPOsEI2Ek1Szmtq59JuTrreFUY 0gfLLBPDluv+UUdSwS41cUkdqYGO2Ef0xm7TkcELGNdAy86a4xymsDJzWQC8J4rVGwFP OTjoYivjAwd0fypFS2iS/iv9KRhmFZ1ATMVfLr3SllWaumHL64SSJoxmh5noPQpLQsen ybxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=vuYYxfHO/zPcYQBLEclWRDog1Ypxlh8KeuaA6+NsDvY=; b=M1hqGnrGudJH6c9Qjqu7VOPlE88ARcGAc52luEN9j2iL53iUvq0ctIj6WpjJohug/y QGTXnRbXSeIPu60XHnrcGLWSYDuMQB1luP3p+bw1lOJ8VvK9rrZmDeVVN3zVhk6YUgLm lRzZV7F/EjFw8MiJXeRoKVyI92t7G6rJ8VTBIV9C6+pIJLHkafrUbdXO6CIyOdTyiRF/ n0PcUUZoLk1k/+D+4tylQoceEkRHol6qdLjAL/LSg1U1UMVEV+xpsXhLT5MKJfT4UUKt c4hI28l7rhjDsdNs/pIRPukVGlIlUKCeVAod5sHWFWh8Vn0THZPxDuUloJSp/DRuWIvp n5MA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Q98YbcV2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y17si3413083edq.356.2021.01.22.00.54.03; Fri, 22 Jan 2021 00:54:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Q98YbcV2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727021AbhAVIwP (ORCPT + 99 others); Fri, 22 Jan 2021 03:52:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727085AbhAVIuh (ORCPT ); Fri, 22 Jan 2021 03:50:37 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41C5AC0613D6 for ; Fri, 22 Jan 2021 00:49:55 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id a20so293810pjs.1 for ; Fri, 22 Jan 2021 00:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vuYYxfHO/zPcYQBLEclWRDog1Ypxlh8KeuaA6+NsDvY=; b=Q98YbcV2IQJMhFLKAD7cFqWyiSmPq/Mcn7y55WxRgs/oAzFCKHNMx94vWoVKBagy3+ r09BMmdHegxPafn40rvPE2dV1xIxT8cekmOrTgf+eokSLTawIbUSIcVkFPd3v6R8YYOy ARvoXJ1NhFJfdSJ+oqenhAx5ALNP4GLlYKqpn0hLNcEOaHLJIh0HLl1W5xrtivm/cvSP 6wkMltPYWzbhe1CkSgA2n0QhtsXwfVsGoJ5fLMoMRaM99GMD+3+pOcxzNjxhRUw/Q2bM wgIEmVGti/lekUNSqMqZm75+NlgMXiRokM+TB/KWDayu+H/b4Q3BNkHdP/LezspKGFIc ouEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vuYYxfHO/zPcYQBLEclWRDog1Ypxlh8KeuaA6+NsDvY=; b=dknup9+LD51mgBuRa71o2LkIrGSVIMlKKWaayyqO3QMm3SKFSbkiqQ1OsMwbm84VlF QJ9nMRjw5LzCNtZIGxAH1bhJE/ecxUhjsouz6MYu7lp6Ano9+a3xY3Q5QbQcYhlXg3xa rie6NHpArAl+zAHh00ITW6K2vRkEH6978ePcCQb4EogUhNwIOa/Xo4si+LngzBX7jWUc adXY0V0fmQNw10E03gLVee1dQQzmOrfX4xCNFvos14secsPFTHu2IdQmGxBAPO30vA2M sGgI8ECd9irzAYV+48DSsLJcIasfv4u0AiNdU+a3j06MoJY1Fgvr0BjADnwIOlNFpUFj 9IOw== X-Gm-Message-State: AOAM533TAWEbNiv212Tys/dkxJ6ooo4/g8BYF6krKCNJIATQM795DJWm 2zFEWtBHANBVnXiZgJu2uFk0+GugJtePQ+GpSmkFDiTPxUZUIQ== X-Received: by 2002:a17:90a:da02:: with SMTP id e2mr4092438pjv.173.1611305394649; Fri, 22 Jan 2021 00:49:54 -0800 (PST) MIME-Version: 1.0 References: <20210107185555.2781221-1-maskray@google.com> <20210114224819.1608929-1-maskray@google.com> In-Reply-To: <20210114224819.1608929-1-maskray@google.com> From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Fri, 22 Jan 2021 00:49:43 -0800 Message-ID: Subject: Re: [PATCH v3] x86: Treat R_386_PLT32 as R_386_PC32 To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML Cc: LKML , clang-built-linux , Arnd Bergmann , Nick Desaulniers , Nathan Chancellor Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 14, 2021 at 2:48 PM Fangrui Song wrote: > > This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as > R_X86_64_PC32"), but for i386. As far as Linux kernel is concerned, > R_386_PLT32 can be treated the same as R_386_PC32. > > R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the > requirement that the symbol address is significant. > R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the > address significance requirement. > > On x86-64, there is no PIC vs non-PIC PLT distinction and an > R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and > `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. > > On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the > convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC > PLT. > > clang-12 -fno-pic (since > https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6) > can emit R_386_PLT32 for compiler generated function declarations as > well to avoid a canonical PLT entry (st_shndx=0, st_value!=0) if the > symbol turns out to be defined externally. GCC/GNU as will likely keep > using R_386_PC32 because (1) the ABI is legacy (2) the change will drop > a GNU ld non-default visibility ifunc for shared objects. > https://sourceware.org/bugzilla/show_bug.cgi?id=27169 > > Link: https://github.com/ClangBuiltLinux/linux/issues/1210 > Reported-by: Arnd Bergmann > Signed-off-by: Fangrui Song > Reviewed-by: Nick Desaulniers > Reviewed-by: Nathan Chancellor > Tested-by: Nick Desaulniers > Tested-by: Nathan Chancellor > > --- > Change in v2: > * Improve commit message > --- > Change in v3: > * Change the GCC link to the more relevant GNU as link. > * Fix the relevant llvm-project commit id. > --- > arch/x86/kernel/module.c | 1 + > arch/x86/tools/relocs.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c > index 34b153cbd4ac..5e9a34b5bd74 100644 > --- a/arch/x86/kernel/module.c > +++ b/arch/x86/kernel/module.c > @@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs, > *location += sym->st_value; > break; > case R_386_PC32: > + case R_386_PLT32: > /* Add the value, subtract its position */ > *location += sym->st_value - (uint32_t)location; > break; > diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c > index ce7188cbdae5..717e48ca28b6 100644 > --- a/arch/x86/tools/relocs.c > +++ b/arch/x86/tools/relocs.c > @@ -867,6 +867,7 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel, Elf_Sym *sym, > case R_386_PC32: > case R_386_PC16: > case R_386_PC8: > + case R_386_PLT32: > /* > * NONE can be ignored and PC relative relocations don't > * need to be adjusted. > @@ -910,6 +911,7 @@ static int do_reloc_real(struct section *sec, Elf_Rel *rel, Elf_Sym *sym, > case R_386_PC32: > case R_386_PC16: > case R_386_PC8: > + case R_386_PLT32: > /* > * NONE can be ignored and PC relative relocations don't > * need to be adjusted. > -- > 2.30.0.296.g2bfb1c46d8-goog > Ping:)