Rollup merge of #145578 - vexide:armv7a-vex-v5+linked-files, r=davidtwco

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, developers can also configure the operating system (VEXos) to preload a separate file at any location between these two addresses before the program starts (as a sort of basic linking or configuration loading 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 linked 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.

It's important for Rust to support this because while VEXos's runtime user-exposed file system APIs may only read data from an external SD card, linked files are allowed 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 a memory region containing a linked file. It expects the linked file to be loaded in the final N bytes of user RAM (this is not technically required but every existing runtime does it this way to avoid having discontinuous memory regions).

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. The linker would prepend this to the builtin target linker script.

```c
/* custom.ld: Reserves 10MiB for a linked file. */
/* (0x7600000-0x8000000) */
__linked_file_length = 10M;

/* The above line is equivalent to -Clink-arg=--defsym=__linked_file_length=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 the above example, `0x7600000`).

Author: jieyouxu

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, _))

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) {