[PATCH] D111181: [llvm-objcopy][ELF] Don't assume RELA sections are dynamic if they carry the SHF_ALLOC flag

Wed Oct 6 16:26:31 PDT 2021

nickdesaulniers added a comment.

In D111181#3046870 <https://reviews.llvm.org/D111181#3046870>, @MaskRay wrote:

> I have considered many linkers (GNU ld, gold, ld.lld) and many loaders (glibc ld.so, musl ld.so, FreeBSD rtld, NetBSD libexec-elf).

I guess the kernel's module loader is the oddball here? It needs to process relocations from dynamically loaded objects.

> While this occurs rarely for normal user programs, the Linux kernel uses partially linked ET_REL objects as its loadable module format

Seems to confirm.

> OK, let's just calm down.

*cringe* //Please// don't tell people that.  We need to be respectful to //everyone//. You and @ardb know more about ELF than anyone I know; you two would make great teammates, if you could learn to play nice.

In D111181#3046669 <https://reviews.llvm.org/D111181#3046669>, @ardb wrote:

> There is some background here:
> https://android-review.googlesource.com/c/kernel/common/+/1842462/3

Perhaps you could isolate the commands used to recreate an ELF object that demonstrates the issues in llvm-strip?  That might help us identify perhaps a different way to achieve the desired outcome? At the very least it would demonstrate how such a binary could be created.  Though it seems your added test case already demonstrates that. @MaskRay is that not enough? I'm guessing `make ... V=1` in KBuild could help isolate the precise tool invocations?

When you refer to "use **a host tool** to tweak the ELF metadata of this module so that the RELA data is preserved and accessible to the module init code." by **host tool** are you referring to `$(OBJTOOL)`?

I'm guessing https://android-review.googlesource.com/c/kernel/common/+/1842462/4/arch/arm64/Makefile.postlink#b11 is part of it?  IIUC, (which I probably don't), we're moving a few sections to two new ones with alloc+readonly? Do they not have alloc beforehand?

> resulting in cryptic error messages such as
> llvm-strip: error: Link field value 48 in section .rela.text is not a symbol table
> where the file in question does in fact have a SYMTAB section at #48.

I think we can all agree that the error message here could be more helpful to the end user.

> we sometimes rely on SHF_ALLOC to indicate to the module loader that the static relocations (which the Linux kernel fixes up at module load time) need to be preserved in memory after loading of the module completes.

I wonder what other loaders do in this case? Perhaps that is the major difference that all of this is predicated on?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111181/new/

https://reviews.llvm.org/D111181