c703f5a163
wasm sections sizes are specified as u32s, and thus can be as large as 4GB. wasm-ld currently stores the offset into a section as an int32_t which overflows on large sections and results in a crash. This change makes it a int64_t to accommodate any valid wasm section and allow catching even larger sections instead of wrapping around. This PR fixes the issue by storing the offset as a int64_t, as well as adding extra checks to handle un-encodeable sections to fail instead of producing garbage wasm binaries, and also adds lit tests to make sure it works. I confirmed the test fails on `main` but passes with this fix. Fixes: #178286
30 lines
1.0 KiB
Plaintext
30 lines
1.0 KiB
Plaintext
# RUN: split-file %s %t
|
|
# RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown %t/debug1.s -o %t/debug1.o
|
|
# RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown %t/debug2.s -o %t/debug2.o
|
|
# --no-gc-sections to prevent the linker from optimizing the chunk away, otherwise it produces a tiny output
|
|
# RUN: wasm-ld --no-entry --no-gc-sections %t/debug1.o %t/debug2.o -o %t/combined.wasm
|
|
# RUN: llvm-readobj --sections %t/combined.wasm | FileCheck %s
|
|
|
|
# Check that the linker doesn't crash with large debug sections that together exceed 2GB.
|
|
# CHECK: Type: CUSTOM (0x0)
|
|
# Total size: 2214592520 + 134217728 = 2348810248
|
|
# CHECK-NEXT: Size: 2348810248
|
|
# CHECK: Name: .debug_info
|
|
|
|
# A 2GB + some extra bytes debug section to make sure we go over 2G
|
|
#--- debug1.s
|
|
.section .debug_info,"",@
|
|
.int32 0xAAAAAAAA
|
|
.int32 0xBBBBBBBB
|
|
.zero 2214592504
|
|
.int32 0xCCCCCCCC
|
|
.int32 0xDDDDDDDD
|
|
|
|
#--- debug2.s
|
|
.section .debug_info,"",@
|
|
.int32 0x11111111
|
|
.int32 0x22222222
|
|
.zero 134217712
|
|
.int32 0x44444444
|
|
.int32 0x55555555
|