Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1346406pxj; Fri, 4 Jun 2021 11:58:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0j/AuCWXCtquobxSkJ6hO3fmH4tlVxUeqyBSTRrcQ9UAFd6Wg+780IayyXvoFMos74SzL X-Received: by 2002:a50:9346:: with SMTP id n6mr6203137eda.365.1622833099413; Fri, 04 Jun 2021 11:58:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622833099; cv=none; d=google.com; s=arc-20160816; b=C4c95hRIlHqikcwDVh7ZiwAkCoVFp57IrBcZ12IzhYO9lQ+MW3TeLZaZCT+QtQbKDN bYqD9U52C+mezrZ3DZYZPlw4qGtiks5LkeOvKy7RasRd4ppgicP1oKvc6SAREx0hjSGR IzfD/PwqA0sCaydkbInnv2NSzoXsbnLeZl5UaUh0Ksucj7Z7ZaVN+/ACvmm0NuaiPnEM pPJk0wVMO1692BLlv29GJZOtcbbX51BFZ6okovAh7ahc51oqylNPz7Fb9JfguaYHnAdk 6i9HaDIWzRXyQ+FpME1No3772kkUM8STb8w15bYsR3MVONodIdSeHrRGtggxJvVW3X+R PDJw== 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=MAY7KM/K0wP2g2AnxgxdYeWiUARA3nmMx/CzXqNh5J8=; b=hbvoJ522StGCHYTe0VzpTUrRM7xECgqiyBWnnvq8h1deXVfbD2P6G0fVQSvgvizEUe CqmxOPkBt9LiZHSElFtNNgm8wu/BbBfkPHFqh5WSzIU6BVH9IebSeC2Rhr1PkK2t6HIq GoThjkVDRKM/6QZKUJXZk+OzYeCAhkcx6vdXe6/Xko8RxPZ44NRNIX47Ltm67FK1R/8s NDxMbXNCe7ratoJcGnEdco2gukVVYDY2h9ltGXgcfHovGroxyawXPDhlB9VPYV8Awk6O /8g+xKtZyud5E6QK3N89XllwKvm8vX2X6XUMzveU53PI215/PfGght5j++9pVysgGvV9 VeYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="ILKJc/Ma"; 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 he38si4792186ejc.308.2021.06.04.11.57.56; Fri, 04 Jun 2021 11:58:19 -0700 (PDT) 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="ILKJc/Ma"; 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 S230286AbhFDS6P (ORCPT + 99 others); Fri, 4 Jun 2021 14:58:15 -0400 Received: from mail-lj1-f174.google.com ([209.85.208.174]:33663 "EHLO mail-lj1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229810AbhFDS6P (ORCPT ); Fri, 4 Jun 2021 14:58:15 -0400 Received: by mail-lj1-f174.google.com with SMTP id o8so12891212ljp.0 for ; Fri, 04 Jun 2021 11:56:17 -0700 (PDT) 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=MAY7KM/K0wP2g2AnxgxdYeWiUARA3nmMx/CzXqNh5J8=; b=ILKJc/Mav+UPrVq/nRH3LXx5XPRG4deEPpGqPf0OLbxHbhYbvIWD/nVaHVVo/0TKu0 s9pBx2hwEFZ7GqyXhTa78xIoF5sYlpyM608nf/SIkgZa7bPVxqPszqJxCdQXXXNa1DyY /QNzow1odGMNaN9fHmSPR6WtoRzo9cTfUK3Bu7A4FvmTmhSB6aAVte85eheGTcQZ+ib9 OERYSFMlsC25mo1f9HXpX8XvUk1Cek2HAV+ymRj/rIxV1BsXGhmm3xSMj4lLqkGM1TVa fofIMGv/yK3ZOD7YISxMitNtPUydzIIxANR65nc68i/mDh/DJaK8arbKunf+8pAUPpUz s/tw== 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=MAY7KM/K0wP2g2AnxgxdYeWiUARA3nmMx/CzXqNh5J8=; b=r0OXk1r4fqpOZh9BVvIlBHQIiKUBbL8fdYCnSg18bhwDUbX/UkaYxDTyq31pPmVkV/ +vH9w8vb9BgeMSxxkfYKcMazbe+57eSGzvUJg9gboUG1gutA2WHeUlH/0Sinrxy/vFpY k2q130jzx/4uT13xjUtNW45TgY46E+G4GVJsGnSoYUvPwqOACT/M+lVqZ3UUTe1ao6y+ IN7QL3aIzDOYwJjg56rlYurVqdzHD/1Zubb1PD3EgKUDZ/XjDYkPSxjG3w1NUSzO5EYj 7qgPjR6Ph+vhv9oIz7YoigSeZqYn3s9BD7vSU+L+/wbz04yzua2NuFBfJGhOit5eNCsb A5nQ== X-Gm-Message-State: AOAM531zx/O06g1woB1EZNaD0Wkca2kxckS8NLYUj/3fn8TRnSDFpoUG sixZI0wFuuHR3QwOnL6hgbYs4qXHmPcvFD+S6f9W8A== X-Received: by 2002:a2e:b6d2:: with SMTP id m18mr4278071ljo.233.1622832916471; Fri, 04 Jun 2021 11:55:16 -0700 (PDT) MIME-Version: 1.0 References: <20210522012626.2811297-1-ndesaulniers@google.com> <20210526170904.GB19831@willie-the-truck> In-Reply-To: <20210526170904.GB19831@willie-the-truck> From: Nick Desaulniers Date: Fri, 4 Jun 2021 11:55:04 -0700 Message-ID: Subject: Re: [PATCH v2] Makefile: fix GDB warning with CONFIG_RELR To: Will Deacon Cc: Catalin Marinas , Linux ARM , Lee Jones , Masahiro Yamada , clang-built-linux , Fangrui Song , Elliot Berman , Sami Tolvanen , Peter Collingbourne , Michal Marek , Linux Kbuild mailing list , LKML , Nathan Chancellor Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 10:09 AM Will Deacon wrote: > > On Fri, May 21, 2021 at 06:26:24PM -0700, Nick Desaulniers wrote: > > GDB produces the following warning when debugging kernels built with > > CONFIG_RELR: > > > > BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn' > > > > when loading a kernel built with CONFIG_RELR into GDB. It can also > > prevent debugging symbols using such relocations. > > > > Peter sugguests: > > [That flag] means that lld will use dynamic tags and section type > > numbers in the OS-specific range rather than the generic range. The > > kernel itself doesn't care about these numbers; it determines the > > location of the RELR section using symbols defined by a linker script. > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1057 > > Suggested-by: Peter Collingbourne > > Reviewed-by: Nathan Chancellor > > Signed-off-by: Nick Desaulniers > > --- > > Changes V1 -> V2: > > * rebase > > * pick up Nathan's reviewed by tag. > > > > Makefile | 2 +- > > scripts/tools-support-relr.sh | 3 ++- > > 2 files changed, 3 insertions(+), 2 deletions(-) > > Does lld support RELR relocations for any architectures other than arm64? If Yes; from what I can tell it's not an architecture specific relocation type. Combing through LLVM's sources, it seems Fuchsia sets it always (at least when using lld) and I'm pretty sure they support x86. At least I don't get any errors out of LLD when building with --pack-dyn-relocs=relr on x86. I can force on RELR for x86 kernel builds with: ``` diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0045e1b44190..513272c77827 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2117,6 +2117,7 @@ config PHYSICAL_START config RELOCATABLE bool "Build a relocatable kernel" + select ARCH_HAS_RELR default y help This builds a kernel image that retains relocation information ``` That builds (it won't boot because we don't have the machinery in the kernel to self relocate that type, yet). > so, is the "--use-android-relr-tags" option supported on all of those as > well? I believe so; no issues building with this patch and with the above diff applied on x86. All that flag does is change the elf section type from SHT_RELR to SHT_ANDROID_RELR. pcc@ can correct me if I'm wrong. -- Thanks, ~Nick Desaulniers