rust - Rustc/LLVM generates faulty code for aarch64 with opt-level=0 -


i have 2 files assembled/compiled/linked minimalistic kernel.

start.s:

    .set cpacr_el1_fpen, 0b11 << 20      .set boot_stack_size, 8 * 1024      .global __boot_stack     .global __start     .global __halt      .bss     .align 16 __boot_stack:     .fill boot_stack_size      .text __start:     /* disable fp , simd traps */     mov x0, #cpacr_el1_fpen     msr cpacr_el1, x0      /* set stack */     adr x0, __boot_stack     add sp, x0, #boot_stack_size      /* call rust entry point */     bl __boot  __halt:     /* halt cpu */     wfi     b __halt 

boot.rs:

#[no_mangle] pub extern fn __boot() {     unsafe {         let ptr = 0x9000000 *mut u8;         *ptr = '!' u8;    } } 

for opt-level=3 resulting code outputs single '!' serial port (as intended). opt-level=0 have strange infinite loop (e.g. '!!!!!!!!!....'). here disassembled dump of problematic code:

0000000000000000 <__kernel_begin>:    0:   d2a00600    mov x0, #0x300000               // #3145728    4:   d5181040    msr cpacr_el1, x0    8:   100007c0    adr x0, 100 <__boot_stack>    c:   9140081f    add sp, x0, #0x2, lsl #12   10:   94000003    bl  1c <__boot>  0000000000000014 <__halt>:   14:   d503207f    wfi   18:   17ffffff    b   14 <__halt>  000000000000001c <__boot>:   1c:   a9bf7bfd    stp x29, x30, [sp,#-16]!   20:   910003fd    mov x29, sp   24:   94000003    bl  30 <aarch64::boot::__boot::__rust_abi>   28:   a8c17bfd    ldp x29, x30, [sp],#16   2c:   d65f03c0    ret  0000000000000030 <aarch64::boot::__boot::__rust_abi>:   30:   d10043ff    sub sp, sp, #0x10   34:   52a12008    mov w8, #0x9000000              // #150994944   38:   2a0803e9    mov w9, w8   3c:   f90007e9    str x9, [sp,#8]   40:   52800428    mov w8, #0x21                   // #33   44:   39000128    strb    w8, [x9]   48:   910043ff    add sp, sp, #0x10   4c:   d65f03c0    ret 

the code tested using qemu-system-aarch64. don't see serious problems (except redundancy). can suggest possible cause of such abnormal behaviour?

p.s. optimised version works properly:

0000000000000000 <__kernel_begin>:    0:   d2a00600    mov x0, #0x300000               // #3145728    4:   d5181040    msr cpacr_el1, x0    8:   1007ffc0    adr x0, 10000 <__boot_stack>    c:   9140081f    add sp, x0, #0x2, lsl #12   10:   94000003    bl  1c <__boot>  0000000000000014 <__halt>:   14:   d503207f    wfi   18:   17ffffff    b   14 <__halt>  000000000000001c <__boot>:   1c:   52a12008    mov w8, #0x9000000              // #150994944   20:   52800429    mov w9, #0x21                   // #33   24:   39000109    strb    w9, [x8]   28:   d65f03c0    ret 

i've succeeded run non-optimised code without abnormalities. notlikethat idea. stack mapped readonly memory.

so i've added offset statement linker script (". = 1024m;") in order make symbols start 1gib (where ram begins). after modification code started work properly.


Comments

Popular posts from this blog

javascript - gulp-nodemon - nodejs restart after file change - Error: listen EADDRINUSE events.js:85 -

Fatal Python error: Py_Initialize: unable to load the file system codec. ImportError: No module named 'encodings' -

javascript - oscilloscope of speaker input stops rendering after a few seconds -