From dbb8190b9cacf2d3e0d4fbb3c71dc2603bb643a8 Mon Sep 17 00:00:00 2001 From: Lewis McClelland Date: Sat, 9 Aug 2025 14:00:17 -0700 Subject: [PATCH 1/2] Add VEXos "linked files" support to `armv7a-vex-v5` Third-party programs running on the VEX V5 platform need a linker script to ensure code and data are always placed in the allowed range `0x3800000-0x8000000` which is read/write/execute. However, users can also configure the operating system to preload a separate file at any location between these two addresses before the program starts (as a sort of basic linking system). Programs have to know about this at compile time - in the linker script - to avoid placing data in a spot that overlaps where the file will be loaded. This is a very popular feature with existing V5 runtimes because it can be used to modify a program's behavior without re-uploading the entire binary to the robot controller. Also, while VEXos's user-exposed file system APIs may only read data from an external SD card, linked files have the advantage of being able to load data directly from the device's onboard storage. This PR adds the `__linked_file_start` symbol to the existing VEX V5 linker script which can be used to shrink the stack and heap so that they do not overlap with the memory region containing a linked file. With these changes, a developer targeting VEX V5 might add a second linker script to their project by specifying `-Clink-arg=-Tcustom.ld` and creating the file `custom.ld` to configure their custom memory layout: ```ld /* Reserve 10MiB for a linked file. */ /* (0x7600000-0x8000000) */ __linked_file_start = __linked_file_end - 10M; /* Optional: specify one or more sections that */ /* represent the developer's custom format. */ SECTIONS { .linked_file_metadata (NOLOAD) : { __linked_file_metadata_start = . . += 1M; __linked_file_metadata_end = . } .linked_file_data (NOLOAD) : { __linked_file_data_start = . . += 9M; __linked_file_data_end = . } } INSERT AFTER .stack; ``` Then, using an external tool like the `vex-v5-serial` crate, they would configure the metadata of their uploaded program to specify the path of their linked file and the address where it should be loaded into memory (in this example, 0x7600000). --- .../targets/armv7a_vex_v5_linker_script.ld | 27 +++++++++++++------ 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/compiler/rustc_target/src/spec/targets/armv7a_vex_v5_linker_script.ld b/compiler/rustc_target/src/spec/targets/armv7a_vex_v5_linker_script.ld index a4783de018309..0f3e6eeee19a3 100644 --- a/compiler/rustc_target/src/spec/targets/armv7a_vex_v5_linker_script.ld +++ b/compiler/rustc_target/src/spec/targets/armv7a_vex_v5_linker_script.ld @@ -17,15 +17,25 @@ PROVIDE(__vcodesig_type = 0); /* V5_SIG_TYPE_USER */ PROVIDE(__vcodesig_owner = 2); /* V5_SIG_OWNER_PARTNER */ PROVIDE(__vcodesig_options = 0); /* none (0) */ -PROVIDE(__user_ram_start = 0x03800000); -PROVIDE(__user_ram_length = 48M); -PROVIDE(__user_ram_end = __user_ram_start + __user_ram_length); /* 0x8000000 */ +__user_ram_start = 0x03800000; +__user_ram_end = 0x08000000; +/* (0x48 =) 72 MiB length */ +__user_ram_length = __user_ram_start - __user_ram_end; -PROVIDE(__code_signature_length = 0x20); +/* + * VEXos provides a method for pre-loading a "linked file" at a specified + * address in User RAM, conventionally near the end, after the primary + * program binary. We need to be sure not to place any data in that location, + * so we allow the user of this linker script to inform the start address of + * this blob. + */ +PROVIDE(__linked_file_length = 0); +PROVIDE(__linked_file_end = __user_ram_end); +PROVIDE(__linked_file_start = __linked_file_end - __linked_file_length); PROVIDE(__stack_length = 4M); -PROVIDE(__heap_end = __user_ram_end - __stack_length); -PROVIDE(__user_length = __heap_start - __user_ram_start); +PROVIDE(__stack_top = __linked_file_start); +PROVIDE(__stack_bottom = __linked_file_start - __stack_length); MEMORY { USER_RAM (RWX) : ORIGIN = __user_ram_start, LENGTH = __user_ram_length @@ -44,7 +54,7 @@ SECTIONS { LONG(__vcodesig_options) FILL(0) - . = __user_ram_start + __code_signature_length; + . = __user_ram_start + 0x20; } > USER_RAM /* @@ -125,7 +135,8 @@ SECTIONS { */ .heap (NOLOAD) : { __heap_start = .; - . = __heap_end; + . = __stack_bottom; + __heap_end = .; } > USER_RAM .stack (NOLOAD) : ALIGN(8) { From 0e47f19ffc934298227e77e49836ee1e335b7b61 Mon Sep 17 00:00:00 2001 From: Lewis McClelland Date: Sat, 9 Aug 2025 15:46:45 -0700 Subject: [PATCH 2/2] Specify linker scripts after user link args --- compiler/rustc_codegen_ssa/src/back/link.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/compiler/rustc_codegen_ssa/src/back/link.rs b/compiler/rustc_codegen_ssa/src/back/link.rs index 3ec0d900994b0..30ad9450aeff4 100644 --- a/compiler/rustc_codegen_ssa/src/back/link.rs +++ b/compiler/rustc_codegen_ssa/src/back/link.rs @@ -2435,6 +2435,13 @@ fn linker_with_args( // Passed after compiler-generated options to support manual overriding when necessary. add_user_defined_link_args(cmd, sess); + // ------------ Builtin configurable linker scripts ------------ + // The user's link args should be able to overwrite symbols in the compiler's + // linker script that were weakly defined (i.e. defined with `PROVIDE()`). For this + // to work correctly, the user needs to be able to specify linker arguments like + // `--defsym` and `--script` *before* any builtin linker scripts are evaluated. + add_link_script(cmd, sess, tmpdir, crate_type); + // ------------ Object code and libraries, order-dependent ------------ // Post-link CRT objects. @@ -2469,8 +2476,6 @@ fn add_order_independent_options( let apple_sdk_root = add_apple_sdk(cmd, sess, flavor); - add_link_script(cmd, sess, tmpdir, crate_type); - if sess.target.os == "fuchsia" && crate_type == CrateType::Executable && !matches!(flavor, LinkerFlavor::Gnu(Cc::Yes, _))