Why my riscv assembly (.s) file is weird?

use core::panic::PanicInfo;
fn panic(_info: &PanicInfo) -> ! {
    loop {}

pub extern "C" fn _start() -> ! {
    let mut x: i32 = 3;
    let mut y: i32 = 2;
    let mut z: i32 = 0;

    z = x + y;
    x = 5;
    y = 3;
    z = x + y;

I want to read the corresponding assembly code generated for riscv32imac.
Did some search and came across following command to emit assembly.
cargo rustc --- --emit asm
This did generate a .s but,
cat target/riscv32imac-unknown-none-elf/debug/deps/riscv_ex1-dc6de515142dfeb8.s shows the following which I dont understand.

.word   .Linfo_string5
        .byte   2
        .word   .Linfo_string6
        .byte   3
        .word   860
.. blah...
      .asciz  "Some"
        .asciz  "Option<&[core::fmt::rt::v1::Argument]>"
        .asciz  "args"
        .asciz  "value"
   .asciz  "*const ArgumentV1"
        .word   999
        .asciz  "&PanicInfo"
        .word   1158
        .asciz  "&str"
        .word   0
... blah ...
        .section        ".note.GNU-stack","",@progbits
        .section        .debug_line,"",@progbits

can someone help me with correct command to read a clean assembly code for rv32imac?

Also what are those in this .s file as I couldn't correlate to my code.

What, in particular, is wrong with the output?

I am looking for some RISC-V assembly code with riscv registers and instructions.

Not sure, but as your program has no input, no output and whatever happens hangs in a loop that does nothing, I suspect all the code is optimised away.

1 Like


riscv64-unknown-elf-objdump -dC on executable gives the following which seems correct.

000110b4 <_start>:
   110b4:       1141                    addi    sp,sp,-16
   110b6:       4515                    li      a0,5
   110b8:       c22a                    sw      a0,4(sp)
   110ba:       450d                    li      a0,3
   110bc:       c42a                    sw      a0,8(sp)
   110be:       4521                    li      a0,8
   110c0:       c62a                    sw      a0,12(sp)
   110c2:       a009                    j       110c4 <_start+0x10>
   110c4:       a001                    j       110c4 <_start+0x10>

so what is the .s file generated and placed on target prefixed with some hash?


you got the right file there should be some blocks starting with .Lfunc_begin containing the instructions the rest you posted are static variables for debug infos

If I use --emit asm I see:

        .section        .text._start,"ax",@progbits
        .globl  _start
        .p2align        1
        .type   _start,@function
        .loc    1 10 0
        addi    sp, sp, -16
        .cfi_def_cfa_offset 16
        addi    a0, zero, 5
        .loc    1 16 5 prologue_end
        sw      a0, 4(sp)
        addi    a0, zero, 3
        .loc    1 17 5
        sw      a0, 8(sp)
        addi    a0, zero, 8
        .loc    1 18 5
        sw      a0, 12(sp)
        .loc    1 19 5
        j       .LBB1_1
        j       .LBB1_1
        .size   _start, .Lfunc_end1-_start

Note that the .Linfo_string* you showed are part of the line table debuginfo.

1 Like

Thanks, yes i see in the file.

        .loc    1 12 0
        addi    sp, sp, -16
        .cfi_def_cfa_offset 16
        addi    a0, zero, 5
        .loc    1 18 5 prologue_end
        sw      a0, 4(sp)
        addi    a0, zero, 3
        .loc    1 19 5
        sw      a0, 8(sp)
        addi    a0, zero, 8
        .loc    1 20 5
        sw      a0, 12(sp)
        .loc    1 23 5
        j       .LBB1_1

But what should I do to get rid of the debug info & just see the raw assembly code in .s file (just the assembled code with address from 0, without linker, without prologue, etc..)?

You can disable debuginfo. It is disabled by default in release mode. For debug mode you can add the following to Cargo.toml:

debug = 0

An infinite loop is a perfectly well defined construct in Rust, unlike in C++. If you see a case where an infinite loop is optimized away, file a bug report.

Yes. Sorry. I don't think I finished saying what I wanted to say there. Never mind, too late now.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.