unknown argument '--change-section-address'

[nickdesaulniers]

Bugzilla Link	45217
Version	trunk
OS	All
Blocks	#4440
CC	@alexshap,@MaskRay,@jh7370,@rupprecht

Extended Description

The Linux kernel has a custom debug format for eBPF (IIUC) called BTF. It looks like it's making use of GNU objcopy's --change-section-address to set the section address to 0:

ClangBuiltLinux/linux@df786c9

It doesn't look like there's any non-default linker script being used, so I'm not sure we could avoid this with a linker script.

[nickdesaulniers]

We'll be able to work around this for now with https://lore.kernel.org/bpf/20200316222518.191601-1-sdf@google.com/T/#u , but leaving this open for now.

[jh7370]

Yup, we haven't implemented this option (yet) in llvm-objcopy. I've not given it too much thought, but it might not fit particularly well with how llvm-objcopy is currently written, since llvm-objcopy works primarily through its program headers and preserves the section layout within those segments. Changing a section's address would require us to somehow place it elsewhere in the object. It's probably possible, but won't be that simple.

Anyway, somebody should take a look at this at some point. If you want a full workaround using llvm-objcopy, you could do the following sequence:

llvm-objcopy --dump-section .BTF=btf.bin file.o
llvm-objcopy --remove-section .BTF file.o
llvm-objcopy --add-section .BFT=btf.bin file.o
(optionally also use --set-section-flags etc as needed).

That will add the section with a zero address, if I'm not mistaken (not actually verified the invocations, but you should get the gist). It might even be possible to combine those into a single command, though there have been some bugs in ordering of these options, and I'm not sure if they've all been fixed yet.

[MaskRay]

torvalds/linux@df786c9 added --change-section-address to work around some dwarves/pahole bug.

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=90ceddcb495008ac8ba7a3dce297841efcd7d584 is in the bpf-next repository to remove dependency on objcopy --change-section-address (as well as 'file format' and 'architecture' parsing logic of llvm-objdump -f output).

Note that the option can split PT_LOAD and rewrite some fields.
objcopy --change-section-address .plt=0 a b

Before:

LOAD 0x000000 0x0000000000200000 0x0000000000200000 0x0005dc 0x0005dc R 0x1000
LOAD 0x0005e0 0x00000000002015e0 0x00000000002015e0 0x0001d0 0x0001d0 R E 0x1000
LOAD 0x0007b0 0x00000000002027b0 0x00000000002027b0 0x0001b0 0x0001b0 RW 0x1000
LOAD 0x000960 0x0000000000203960 0x0000000000203960 0x000030 0x000031 RW 0x1000

After:

LOAD 0x000000 0x0000000000200000 0x0000000000200000 0x0005dc 0x0005dc R 0x1000
LOAD 0x0005e0 0x00000000002015e0 0x00000000002015e0 0x0001a5 0x0001a5 R E 0x1000
LOAD 0x001000 0x0000000000000000 0x0000000000000000 0x000020 0x000020 R E 0x1000
LOAD 0x0017b0 0x00000000002027b0 0x00000000002027b0 0x0001b0 0x0001b0 RW 0x1000
LOAD 0x001960 0x0000000000203960 0x0000000000203960 0x000030 0x000031 RW 0x1000

I suspect this option won't fit in llvm-objcopy's model (llvm-objcopy/ELF/Object.cpp: layoutSegments/layoutSections). --change-section-address stands for updating both VMA and LMA. It is even less clear how LMA can be updated.

[jh7370]

That program header table in the "After" example looks illegal to me, based on the gABI (loadable segments must be in address order). Does the Linux kernel require this section to be in a program header?

Not tried this yet, but I wouldn't be all that surprised if adding a program header in llvm-objcopy is actually relatively straightforward. If the section would be moved so that you need to split the segment, you could create PT_LOAD, assign the section to it, probably mess about with some offsets, and derive the segment contents from the section. We'd still end up with the old section's contents in the old segment, but this is probably harmless, and could even be changed to blank it out like when a section is explicitly removed. What won't work though is if there are any references to this section (I'm thinking dynamic relocations, or even direct references from code/data etc). As such, I'm not convinced this solution's generality.

[subnut]

#98664