LLVM error: EmitRawText called on an MCStreamer that doesn't support it, something must not be fully mc'ized

[lexxvir]

Hi,

I encountered to LLVM fatal error when try to use alloc crate (along with GlobalAlloc) in Rust:
"EmitRawText called on an MCStreamer that doesn't support it, something must not be fully mc'ized"

It seems that somebody (Rust compiler?) try to emit object code by somehow reason, but because Espressif's llvm branch can't do it, LLVM aborts compilation.

What do you think?
If you have any thought how to workaround this issue I'd like to check it.

This code reproduce issue:
lexxvir@d3edbed

[MabezDev]

Your example compiles fine when I remove the extern crate alloc?

#![no_std]
#![no_main]
// #![feature(alloc)]
#![feature(alloc_error_handler)]

// extern crate alloc;

use core::panic::PanicInfo;
use core::sync::atomic::{self, Ordering};

use panic_ramdump as _;

use core::alloc::{GlobalAlloc, Layout};
use core::ptr::null_mut;

struct MyAllocator;

unsafe impl GlobalAlloc for MyAllocator {
    unsafe fn alloc(&self, _layout: Layout) -> *mut u8 { null_mut() }
    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {}
}

#[alloc_error_handler]
fn foo(_: core::alloc::Layout) -> ! {
    panic!()
}

#[global_allocator]
static A: MyAllocator = MyAllocator;

#[no_mangle]
fn main() {
    
}

#[doc(hidden)]
#[no_mangle]
#[link_section = ".iram0.vectors"]
pub unsafe extern "C" fn Reset() -> ! {
    // CURRENTLY DOES NOTHING
    loop {
        
    }
}

#[doc(hidden)]
#[no_mangle]
pub unsafe extern "C" fn _start() -> ! {
    // CURRENTLY DOES NOTHING
    loop {
        
    }
}

Have you modified the build script to use your rustc path, etc?

[lexxvir]

Yes, issue occurs only when I import alloc crate (extern crate alloc).
Yes, i've modified path to rustc to point to my custom rustc (regular rustc + your patches). Also I've tried build libcore/liballoc/etc by rustc when building it. Also I've tried cargo xbuild. All have the same issue.

[MabezDev]

I see, I can reproduce your issue now.

Not sure what the issue is though. liballoc compiles fine with xargo, so I am not sure what hasn't been mc'ized

[lexxvir]

If you have time, please compile LLVM with ENABLE_BACKTRACES enabled macro. Probably it give us stacktrace where issue occurs.

[MabezDev]

I rebuilt LLVM with backtraces and rebuilt rustc with some of the debug options, still not getting anymore output.

[bjoernQ]

Thanks @MabezDev and @lexxvir for your work on this - already amazing given the implementation status of LLVM-xtensa

I also hit this problem with alloc and my guess (I'm not too experienced with LLVM and hacking rust-lang) is that the problem is caused by the compiler_builtins which alloc depends on? Since there is a lot of C code and/or asm!(...) macros involved - and I think MCStreamer is used when the compiler hits asm!(..) macros (but I might be wrong)

I hope to get some spare time to investigate this but just wanted to share my thoughts

[lexxvir]

Hi guys,

I somehow workaround this issue (but probably for first time though). As I understand, Rust compiler generates "on the fly" function shims for global allocator (see __rust_alloc and friends). And that behavior somehow breaks xtensa LLVM (most probably because it don't support object code generation yet).

My workaround contains two hacks:

1. Force MCStreamer to write 'raw text', see attached patch
2. Force Rust compiler to use usual external "C" function for all allocation stuff, see lexxvir/rust-xtensa@7b2dbe6. This functions must be implemented in target crate (I use malloc/free from ESP IDF).

With these hacks I successfully built and ran my tests that required allocation and FreeRTOS tasks.

emit_bytes.patch.txt

[bjoernQ]

Based on your workaround I created another workaround at https://github.com/bjoernQ/rust-xtensa

It works with unmodified llvm-xtensa head and works with an allocator in the usual way (i.e. #[global_allocator])

Maybe it's useful for you

[lexxvir]

Thank you @bjoernQ! I'll try your trick in the near time.

[lexxvir]

@bjoernQ I have tried your workaround, it's work for me too.

[bjoernQ]

That's great news - thanks for testing