如何获取objcopy生成的二进制镜像入口点？RISC-V模拟器加载疑问

Hey there! Let's work through these RISC-V simulator loading issues step by step—you're already really close with your POC and Rust test program, so let's get this sorted.

1. Where to load the binary into simulator memory? #

Don’t load the entire sample1.bin file into a single offset—this is your main issue right now. The objcopy -O binary command concatenates all loadable sections (like .text, .rodata, .data) into one file, but it loses critical information about where each section should live in memory.

Instead, you need to parse the ELF file's Program Headers to know exactly where each section belongs. Here's how to inspect this:

riscv32-unknown-linux-gnu-readelf -l target/riscv32i-unknown-none-elf/release/sample1

Look for entries with Type: LOAD—each will show:

• p_vaddr: The virtual address where this section should be loaded in your simulator's memory
• p_offset: The offset in the ELF file where the section's data starts
• p_filesz: The size of the data in the ELF file (load this into memory at p_vaddr)
• p_memsz: The total size the section needs in memory (fill the remaining p_memsz - p_filesz bytes with zeros—this is for .bss sections which are zero-initialized)

For example, if your .text section has a p_vaddr of 0x80000000, you'll write the corresponding bytes from the ELF file to your simulator's memory starting at 0x80000000, not at 0x0.

2. How to get the entry point address for the PC register? #

The ELF file header directly stores the entry point address (which points to your _start function). To view it:

riscv32-unknown-linux-gnu-readelf -h target/riscv32i-unknown-none-elf/release/sample1

Look for the line labeled Entry point address—this is the value you should set your CPU's PC register to start execution.

You don't need to guess based on the binary file's contents—this value is explicitly stored in the ELF metadata.

3. How to fix the entry point address for all programs? #

Use a custom linker script to enforce a fixed entry point and section addresses. This way, every program you build will use the same memory layout, so you won't have to adjust your simulator for each test.

1. Create a file named linker.ld with this content (adjust addresses to match your simulator's memory map—0x80000000 is a common starting address for RISC-V RAM):

ENTRY(_start)

MEMORY
{
  RAM (wxr) : ORIGIN = 0x80000000, LENGTH = 16M  # 16MB of RAM
  STACK (wx) : ORIGIN = 0x80100000, LENGTH = 8K   # Stack grows downward from 0x80100000
}

SECTIONS
{
  .text : {
    *(.text .text.*)  # All text sections (your code)
  } > RAM

  .rodata : {
    *(.rodata .rodata.*)  # Read-only data (like panic strings)
  } > RAM

  .data : {
    *(.data .data.*)  # Initialized data
  } > RAM

  .bss : {
    *(.bss .bss.*)    # Zero-initialized data
  } > RAM
}

2. Build your Rust program with this linker script:

RUSTFLAGS="-C link-arg=-Tlinker.ld" cargo build --target riscv32i-unknown-none-elf --release

Now your _start function will always be at 0x80000000 (the start of the .text section in our linker script), so you can hardcode this address as your simulator's initial PC value.

4. Is your objcopy usage incorrect? #

Yes—using objcopy -O binary discards the ELF metadata that tells you where to load each section. For a simulator, the correct approach is to parse the ELF file directly (using an ELF parsing library, or writing simple parser code for the headers) and load each LOAD section to its specified p_vaddr.

If you don't want to write ELF parsing code right now, you can extract individual sections with objcopy and load them manually:

# Extract .text section to a binary, load to 0x80000000
riscv32-unknown-linux-gnu-objcopy -j .text -O binary sample1 sample1.text.bin

# Extract .rodata section, load to its address from readelf
riscv32-unknown-linux-gnu-objcopy -j .rodata -O binary sample1 sample1.rodata.bin

But parsing the ELF file is the scalable solution for any program you build.

Quick note on stack setup #

You mentioned you plan to handle stack initialization later—with the linker script above, you can set the stack pointer at the start of _start:

#[no_mangle]
pub extern "C" fn _start() -> ! {
    // Initialize stack pointer to the start of the STACK region (grows downward)
    unsafe {
        core::arch::asm!("li sp, 0x80100000");
    }

    loop {
        for i in 0..1000 {
            unsafe {
                let r = i as *mut u32;
                *r = 20000 % (500 - i);
            }
        }
    }
}

内容的提问来源于stack exchange，提问作者Tom Kris