| Issue |
63811
|
| Summary |
LLVM ERROR: malformed uleb128, extends past end (lld, wasm module asm, Windows)
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
CAD97
|
I triggered this from Rust so the minimized repro is in Rust; I don't know how to get this into clang/llvm terms on Windows. Asking rustc to emit `.ll`, `.s`, or `.bc` doesn't hit the error, so this is probably a code generator issue, IIUC. I've also provided the `.ll` and `.s`, but couldn't find the entry points to reproduce from those (the rust distribution exposes a rust-lld but not a rust-llc, as far as I can tell).
<details><summary>Version info</summary>
```text
$ rustc -Vv
rustc 1.73.0-nightly (8ca44ef9c 2023-07-10)
binary: rustc
commit-hash: 8ca44ef9caa4049d584fbbce218c219cdca33a2f
commit-date: 2023-07-10
host: x86_64-pc-windows-msvc
release: 1.73.0-nightly
LLVM version: 16.0.5
$ rust-lld -flavor wasm --version --verbose
LLD 16.0.5
```
-----
</details>
<details><summary>Rust reproduction</summary>
```rust
#![feature(asm_experimental_arch)]
#![no_std]
core::arch::global_asm! {
r#"
.section .text.make_answer,"",@
.globl make_answer
.type make_answer,@function
make_answer:
end_function
"#,
}
#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
loop {}
}
```
Compile with `rustc --edition=2021 src\lib.rs --crate-type=cdylib --target wasm32-unknown-unknown`.
-----
</details>
<details><summary>LLVM-IR</summary>
Add `--emit=llvm-ir` to the `rustc` invocation to generate a `.ll` file. This step does not result in any errors.
```rust
; ModuleID = 'lib.ade653b175f4ee81-cgu.0'
source_filename = "lib.ade653b175f4ee81-cgu.0"
target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20"
target triple = "wasm32-unknown-unknown"
module asm ""
module asm " .section .text.make_answer,\22\22,@"
module asm " .globl make_answer"
module asm " .type make_answer,@function"
module asm " make_answer:"
module asm " end_function"
module asm " "
; Function Attrs: noreturn nounwind
define hidden void @rust_begin_unwind(ptr align 4 %_info) unnamed_addr #0 {
start:
br label %bb1
bb1: ; preds = %bb1, %start
br label %bb1
}
attributes #0 = { noreturn nounwind "target-cpu"="generic" }
```
-----
</details>
<details><summary>asm</summary>
Similarly, `--emit=asm` stops compilation before the error occurs.
```asm
.text
.file "lib.ade653b175f4ee81-cgu.0"
.section .text.make_answer,"",@
.globl make_answer
make_answer:
end_function
.tabletype __indirect_function_table, funcref
.functype rust_begin_unwind (i32) -> ()
.section .text.rust_begin_unwind,"",@
.hidden rust_begin_unwind
.globl rust_begin_unwind
.type rust_begin_unwind,@function
rust_begin_unwind:
.functype rust_begin_unwind (i32) -> ()
.LBB0_1:
loop
br 0
.LBB0_2:
end_loop
end_function
.section .custom_section.target_features,"",@
.int8 2
.int8 43
.int8 15
.ascii "mutable-globals"
.int8 43
.int8 8
.ascii "sign-ext"
.section .text.rust_begin_unwind,"",@
```
It looks like perhaps the `.type` didn't make it through translation?
-----
</details>
<details><summary>LLD error</summary>
Unfortunately I wasn't able to find the tool to provide `.ll` directly to on Windows (the rust distribution provides a `rust-lld` but not a `rust-llc`), so reproduction uses the `.o` produced by the previous `rustc` invocation. None of the `-L` arguments provided by rustc are actually needed for this reproduction, so this copy of the error is generated without them.
```text
LLVM ERROR: malformed uleb128, extends past end
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: D:\\.rust\\rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\bin\\rust-lld.exe -flavor wasm --rsp-quoting=posix --export=__heap_base --export=__data_end -z stack-size=1048576 --stack-first --allow-undefined --fatal-warnings --no-demangle --no-entry lib.lib.ade653b175f4ee81-cgu.0.rcgu.o -o lib.wasm --gc-sections --no-entry -O0
Exception Code: 0xC000001D
#0 0x00007ff6afbdf9c6 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1aff9c6)
#1 0x00007ff6afb8ef5e (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1aaef5e)
#2 0x00007ff6afb8f194 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1aaf194)
#3 0x00007ff6afbe6a9a (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1b06a9a)
#4 0x00007ff6afbe6944 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1b06944)
#5 0x00007ff6b061ae78 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x253ae78)
#6 0x00007ff6b0615e48 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x2535e48)
#7 0x00007ff6b0613ff0 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x2533ff0)
#8 0x00007ff6b0613943 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x2533943)
#9 0x00007ff6b06135b5 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x25335b5)
#10 0x00007ff6af60051e (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x152051e)
#11 0x00007ff6af602131 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1522131)
#12 0x00007ff6af5fae5e (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x151ae5e)
#13 0x00007ff6ae3e2792 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x302792)
#14 0x00007ff6ae3d4b98 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x2f4b98)
#15 0x00007ff6ae3d08ea (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x2f08ea)
#16 0x00007ff6ae3cce50 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x2ece50)
#17 0x00007ff6ae0e1cac (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1cac)
#18 0x00007ff6ae0e1438 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1438)
#19 0x00007ff6afb7b3b8 (D:\.rust\rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\bin\rust-lld.exe+0x1a9b3b8)
#20 0x00007fff12f626ad (C:\WINDOWS\System32\KERNEL32.DLL+0x126ad)
#21 0x00007fff13f8aa68 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x5aa68)
```
-----
</details>
Rust sets the flag to make `llvm_unreachable` generate `trap`, and the exit code is STATUS_ILLEGAL_INSTRUCTION, so the error probably comes from one of those.
<details><summary>Variations</summary>
Module level asm of
```asm
.section .text.make_answer,"",@
.globl make_answer
.type make_answer,@function
make_answer:
end_function
```
is causing a crash with STATUS_ILLEGAL_INSTRUCTION, printing LLVM ERROR: malformed uleb128, extends past end;
```asm
.section .text.make_answer,"",@
.globl make_answer
.type make_answer,@function
make_answer:
.functype make_answer () -> ()
end_function
```
causes a silent crash due to STATUS_ACCESS_VIOLATION without printing anything; and
```asm
.functype make_answer () -> ()
.section .text.make_answer,"",@
.globl make_answer
.type make_answer,@function
make_answer:
.functype make_answer () -> ()
end_function
```
compiles without crashing... sometimes. It seems essentially random whether this crashes or not.
-----
</details>
XY: I'm attempting to play around with defining `externref`-speaking functions directly, without using a post-processing step. I built the GAS syntax by looking at `--emit=asm` and mirroring what was done there; as such there's likely all sorts of "you're holding it wrong" in how I was trying to do things. But LLVM still shouldn't be crashing. There's [other](https://github.com/llvm/llvm-project/commit/ef7ca14) cases of wasm codegen reaching `llvm_unreachable` getting fixed; this is likely another one of those.
I would try to reproduce with trunk llc on godbolt compiler explorer, but if it's possible to get it to do the codegen step, I don't know how.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
