elf: add support for rodata sections already aligned to MM_PROGRAM_START #301
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alessandrod
force-pushed
the
rodata-at-vaddr
branch
from
bf96f53
to
27563f9
Compare
Lichtso
reviewed
Apr 20, 2022
| /// with the given range. | ||
| Borrowed(Range<usize>), | ||
| /// The first field is the offset of the section from MM_PROGRAM_START. The | ||
| /// second field an be used to index the input ELF buffer to retrieve the |
| @@ -450,10 +458,16 @@ impl<E: UserDefinedError, I: InstructionMeter> Executable<E, I> { | |||
| } else { | |||
| String::default() | |||
| }, | |||
| vaddr: text_section.sh_addr.saturating_add(ebpf::MM_PROGRAM_START), | |||
| vaddr: if config.optimize_rodata && text_section.sh_addr >= ebpf::MM_PROGRAM_START { | |||
There was a problem hiding this comment.
Do I understand correctly that this assumes that the virtual address is encoded as an offset to ebpf::MM_PROGRAM_START?
There was a problem hiding this comment.
No, the virtual address includes ebpf::MM_PROGRAM_START, therefore being the final address. This is essentially .text 0x100000000 : { *(.text*) } in the linker script.
alessandrod
force-pushed
the
rodata-at-vaddr
branch
from
27563f9
to
4fdd6ac
Compare
When config.enable_elf_vaddr=true, allow for sections to be already aligned to MM_PROGRAM_START at link time. This is a pre-requisite for entirely disabling relocations down the line. In addition to logic changes in parse_ro_section() to relax the previous sh_addr = sh_offset assumption, fix relocations involving addresses above the 32bit address space (MM_PROGRAM_START = 1 << 32). See anza-xyz/llvm-project#35. Finally, this adds end to end tests for R_BPF_64_64 and R_BPF_64_RELATIVE relocations.
alessandrod
force-pushed
the
rodata-at-vaddr
branch
from
4fdd6ac
to
26ed44d
Compare
alessandrod
added a commit
to alessandrod/llvm-project
that referenced
this pull request
May 7, 2022
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
alessandrod
added a commit
to anza-xyz/llvm-project
that referenced
this pull request
May 7, 2022
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
dmakarov
pushed a commit
to dmakarov/llvm-project
that referenced
this pull request
Jul 18, 2022
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
dmakarov
pushed a commit
to dmakarov/llvm-project
that referenced
this pull request
Nov 16, 2022
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
dmakarov
pushed a commit
to dmakarov/llvm-project
that referenced
this pull request
Dec 12, 2022
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
dmakarov
pushed a commit
to dmakarov/llvm-project
that referenced
this pull request
Mar 17, 2023
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
18 tasks
dmakarov
pushed a commit
to dmakarov/llvm-project
that referenced
this pull request
Sep 10, 2023
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
LucasSte
pushed a commit
to LucasSte/llvm-project
that referenced
this pull request
Jan 31, 2024
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
LucasSte
pushed a commit
to anza-xyz/llvm-project
that referenced
this pull request
Feb 16, 2024
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
LucasSte
pushed a commit
to LucasSte/llvm-project
that referenced
this pull request
Jun 28, 2024
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
LucasSte
pushed a commit
to anza-xyz/llvm-project
that referenced
this pull request
Aug 19, 2024
Relocate FK_Data_8 fixups as R_BPF_64_ABS64. R_BPF_64_64 is used for ldimm64 which only makes sense in .text. Currently 64 bit values in non-text sections get chopped to 32 bits and shifted 32 bits to the left (that is, the first 8 bytes of a ldimm64 relocation). This commit fixes it so that 64 bit values get written fully at the intended offset. For backwards compatibility, the new behaviour is used only if the reloc-abs64 feature is on (required by -mcpu=sbfv2), since rbpf before solana-labs/rbpf#301 assumes the legacy buggy layout.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When
config.enable_elf_vaddr=true, allow for sections to be already aligned toMM_PROGRAM_STARTat link time. This is a prerequisite for entirely disabling relocations down the line. I've put it behindconfig.optimize_rodatasince we haven't enabled that yet and it is somewhat an extension of that feature.In addition to logic changes in
parse_ro_section()to relax the previoussh_addr = sh_offsetassumption, this fixes relocations involving addresses above the 32bit address space (MM_PROGRAM_START = 1 << 32). Seeanza-xyz/llvm-project#35.
I've added end to end tests for both
R_BPF_64_64andR_BPF_64_RELATIVErelocs.The idea is that with this (
R_BPF_64_64andR_BPF_64_RELATIVErelocations become optional since addresses are already withinMM_PROGRAM_START), plus #296 (no more syscall relocations), we get closer to the point where we don't need to apply any runtime relocations for new programs.