add more descriptive comments to the armv7a-vex-v5 linkerscript

Author: Tropix126

compiler/rustc_target/src/spec/targets/armv7a_vex_v5_linker_script.ld

@@ -11,6 +11,7 @@ __code_signature_length = 0x20;
 __stack_length = 0x400000;
 __heap_end = __user_ram_end - __stack_length;
 
+/* see https://github.com/llvm/llvm-project/blob/main/libunwind/src/AddressSpace.hpp#L78 */
 __eh_frame_hdr_start = SIZEOF(.eh_frame_hdr) > 0 ? ADDR(.eh_frame_hdr) : 0;
 __eh_frame_hdr_end = SIZEOF(.eh_frame_hdr) > 0 ? . : 0;
 
@@ -19,6 +20,13 @@ MEMORY {
 }
 
 SECTIONS {
+    /*
+     * VEXos expects program binaries to have a 32-byte header called a "code signature",
+     * at their start, which tells the OS that we are a valid program and configures some
+     * miscellaneous startup behavior.
+     * 
+     * This section is then initialized as a weak symbol in our PAL.
+     */
     .code_signature : {
         KEEP(*(.code_signature))
         . = __user_ram_start + __code_signature_length;
@@ -29,6 +37,7 @@ SECTIONS {
         *(.text .text.*)
     } > USER_RAM
 
+    /* Global/uninitialized/static/constant data sections. */
     .rodata : {
         *(.rodata .rodata.*)
     } > USER_RAM
@@ -43,8 +52,10 @@ SECTIONS {
         __bss_end = .;
     } > USER_RAM
 
-    /* The unwind tables enabled by "default-uwtable" in the target file live here. */
-    /* __eh_frame_start and similar symbols are used by libunwind. */
+    /*
+     * These sections are added by the compiler in some cases to facilitate stack unwinding.
+     * __eh_frame_start and similar symbols are used by libunwind.
+     */
     .eh_frame_hdr : {
         KEEP(*(.eh_frame_hdr))
     } > USER_RAM
@@ -67,6 +78,7 @@ SECTIONS {
         __extab_end = .;
     } > USER_RAM
 
+    /* Active memory regions for the stack/heap. */
     .heap (NOLOAD) : ALIGN(4) {
         __heap_start = .;
         . = __heap_end;
@@ -78,6 +90,10 @@ SECTIONS {
         __stack_top = .;
     } > USER_RAM
 
+    /*
+     * `.ARM.attributes` contains arch metadata for compatibility purposes, but we
+     * only target one hardware configuration, meaning it'd just take up space.
+     */
     /DISCARD/ : {
         *(.ARM.attributes*)
     }