-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
elf: add support for rodata sections already aligned to MM_PROGRAM_START #301
Conversation
bf96f53
to
27563f9
Compare
/// 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"an be" should be "is" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I meant "can be"
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the virtual address includes ebpf::MM_PROGRAM_START
, therefore being the final address. This is essentially .text 0x100000000 : { *(.text*) }
in the linker script.
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.
4fdd6ac
to
26ed44d
Compare
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
When
config.enable_elf_vaddr=true
, allow for sections to be already aligned toMM_PROGRAM_START
at link time. This is a prerequisite for entirely disabling relocations down the line. I've put it behindconfig.optimize_rodata
since 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_offset
assumption, 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_64
andR_BPF_64_RELATIVE
relocs.The idea is that with this (
R_BPF_64_64
andR_BPF_64_RELATIVE
relocations 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.