On Thu, Mar 18, 2021 at 05:07:06PM -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 <p...@google.com> > Signed-off-by: Nick Desaulniers <ndesaulni...@google.com>
Reviewed-by: Nathan Chancellor <nat...@kernel.org> > --- > Makefile | 2 +- > scripts/tools-support-relr.sh | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 5160ff8903c1..47741cb60995 100644 > --- a/Makefile > +++ b/Makefile > @@ -1088,7 +1088,7 @@ LDFLAGS_vmlinux += $(call ld-option, -X,) > endif > > ifeq ($(CONFIG_RELR),y) > -LDFLAGS_vmlinux += --pack-dyn-relocs=relr > +LDFLAGS_vmlinux += --pack-dyn-relocs=relr --use-android-relr-tags > endif > > # We never want expected sections to be placed heuristically by the > diff --git a/scripts/tools-support-relr.sh b/scripts/tools-support-relr.sh > index 45e8aa360b45..cb55878bd5b8 100755 > --- a/scripts/tools-support-relr.sh > +++ b/scripts/tools-support-relr.sh > @@ -7,7 +7,8 @@ trap "rm -f $tmp_file.o $tmp_file $tmp_file.bin" EXIT > cat << "END" | $CC -c -x c - -o $tmp_file.o >/dev/null 2>&1 > void *p = &p; > END > -$LD $tmp_file.o -shared -Bsymbolic --pack-dyn-relocs=relr -o $tmp_file > +$LD $tmp_file.o -shared -Bsymbolic --pack-dyn-relocs=relr \ > + --use-android-relr-tags -o $tmp_file > > # Despite printing an error message, GNU nm still exits with exit code 0 if > it > # sees a relr section. So we need to check that nothing is printed to stderr. > -- > 2.31.0.rc2.261.g7f71774620-goog >
