What causes "got a non-UTF8 data-layout from LLVM" in rust-lang/rust?

Verify the `--target` triple is valid and supported by both rustc and the linked LLVM.

got a non-UTF8 data-layout from LLVM

Error message

got a non-UTF8 data-layout from LLVM

What it means

This panic occurs in `context.rs` when rustc reads the target data-layout string back from the LLVM module via `LLVMGetDataLayoutStr(llmod)` and converts the raw `CStr` bytes to a Rust `&str`. `str::from_utf8(...).expect("got a non-UTF8 data-layout from LLVM")` panics if the bytes are not valid UTF-8. The data-layout is fundamental to ABI correctness, so a malformed string is treated as a fatal LLVM/target inconsistency rather than silently propagated.

Source

Thrown at compiler/rustc_codegen_llvm/src/context.rs:238

    }
    if llvm_version < (23, 0, 0) {
        if sess.target.arch == Arch::S390x {
            // LLVM 23 updated the s390x layout to specify the stack alignment: https://github.com/llvm/llvm-project/pull/176041
            target_data_layout = target_data_layout.replace("-S64", "");
        }
    }

    // Ensure the data-layout values hardcoded remain the defaults.
    {
        let tm = crate::back::write::create_informational_target_machine(sess, false);
        unsafe {
            llvm::LLVMRustSetDataLayoutFromTargetMachine(llmod, tm.raw());
        }

        let llvm_data_layout = unsafe { llvm::LLVMGetDataLayoutStr(llmod) };
        let llvm_data_layout =
            str::from_utf8(unsafe { CStr::from_ptr(llvm_data_layout) }.to_bytes())
                .expect("got a non-UTF8 data-layout from LLVM");

        if target_data_layout != llvm_data_layout {
            tcx.dcx().emit_err(crate::diagnostics::MismatchedDataLayout {
                rustc_target: sess.opts.target_triple.to_string().as_str(),
                rustc_layout: target_data_layout.as_str(),
                llvm_target: sess.target.llvm_target.borrow(),
                llvm_layout: llvm_data_layout,
            });
        }
    }

    let data_layout = SmallCStr::new(&target_data_layout);
    unsafe {
        llvm::LLVMSetDataLayout(llmod, data_layout.as_ptr());
    }

    let llvm_target = SmallCStr::new(&versioned_llvm_target(sess));
    unsafe {

View on GitHub (pinned to 22057b88b0)

Solutions

Verify the `--target` triple is valid and supported by both rustc and the linked LLVM.
Use the rustc toolchain's bundled LLVM rather than a system LLVM of a different version.
Rebuild rustc from source so the `rustc_codegen_llvm` crate matches the LLVM it links against.
Reproduce with `-Zverbose` and report the offending triple/data-layout to the rustc issue tracker if it persists on a stock toolchain.

Example fix

// before
rustc --target=x86_64-unknown-linux-gn-   # typo in triple
// after
rustc --target=x86_64-unknown-linux-gnu

Defensive patterns

Strategy: validation

Validate before calling

# The data-layout string returned by LLVM is not valid UTF-8, which means the
# LLVM/rustc linkage is corrupt or ABI-incompatible. Probe before building.
rustc -vV >/dev/null 2>&1 || { echo 'rustc binary broken'; exit 1; }
# A self-consistent toolchain can print its target's data layout as UTF-8.
rustc --print=data-layout 2>&1 | LC_ALL=C grep -Eq '^[A-Za-z0-9-]+$' \
  || { echo 'data-layout probe failed; toolchain/LLVM mismatch'; exit 1; }

Try / catch

out="$(cargo build 2>&1)"; rc=$?
if [ $rc -ne 0 ]; then
  case "$out" in
    *"got a non-UTF8 data-layout from LLVM"*)
      echo "rustc/LLVM ABI mismatch; reinstall the toolchain via rustup" >&2
      rustup toolchain uninstall "$(rustup show active-toolchain | awk '{print $1}')" 2>/dev/null
      echo "then: rustup toolchain install stable" >&2 ;;
    *) echo "$out" >&2 ;;
  esac
  exit $rc
fi

Prevention

Never mix a rustc binary from one manifest with libLLVM from another; always install both via the same rustup release.
Avoid LD_LIBRARY_PATH / DYLD_LIBRARY_PATH overrides that point rustc at a foreign libLLVM.
Reinstall the toolchain (rustup toolchain uninstall && install) if a system upgrade touched LLVM libraries.
Pin the toolchain in rust-toolchain.toml so CI and teammates cannot pick up a drifted LLVM.
If you build rustc yourself, link against the exact LLVM revision listed in src/llvm-project.

When it happens

Trigger: After `LLVMRustSetDataLayoutFromTargetMachine` writes the layout into the module, rustc reads it back (context.rs:235-238) and asserts UTF-8 validity. The panic fires only if LLVM returns bytes that are not valid UTF-8 — e.g. a corrupted target triple, a target whose data-layout was misconfigured in LLVM, or a buggy/custom LLVM build that emits garbage for the triple.

Common situations: Using an unusual or mistyped `--target` triple whose LLVM target has no valid data-layout; a custom LLVM build that returns a non-null-terminated or invalid string; memory corruption from an FFI mismatch; running rustc against an incompatible LLVM shared library version.

Related errors

AI-assisted analysis of rust-lang/rust@22057b88b0 (2026-08-03). Data as JSON: /data/errors/920ed9e2270df33d.json. Report an issue: GitHub.