linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Lee Jones <lee.jones@linaro.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	 clang-built-linux <clang-built-linux@googlegroups.com>,
	Fangrui Song <maskray@google.com>,
	 Elliot Berman <eberman@quicinc.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	 Peter Collingbourne <pcc@google.com>,
	Michal Marek <michal.lkml@markovi.net>,
	 Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH v2] Makefile: fix GDB warning with CONFIG_RELR
Date: Fri, 4 Jun 2021 11:55:04 -0700	[thread overview]
Message-ID: <CAKwvOd=Ah8LL2XDXQE9=t1hGNTxfeGEmVkVdhUBoQ5P_9eAWhA@mail.gmail.com> (raw)
In-Reply-To: <20210526170904.GB19831@willie-the-truck>

On Wed, May 26, 2021 at 10:09 AM Will Deacon <will@kernel.org> 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 <pcc@google.com>
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-04 18:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAK7LNAS_LpZnweujqVwZ1kL0eDYR726k35U_yx1djqNE0bk6Rw@mail.gmail.com>
2021-05-22  1:26 ` [PATCH v2] Makefile: fix GDB warning with CONFIG_RELR Nick Desaulniers
2021-05-26 17:09   ` Will Deacon
2021-06-04 18:55     ` Nick Desaulniers [this message]
2021-06-08 13:21   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKwvOd=Ah8LL2XDXQE9=t1hGNTxfeGEmVkVdhUBoQ5P_9eAWhA@mail.gmail.com' \
    --to=ndesaulniers@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=eberman@quicinc.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=michal.lkml@markovi.net \
    --cc=nathan@kernel.org \
    --cc=pcc@google.com \
    --cc=samitolvanen@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).