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
36 lines
1.1 KiB
Plaintext
36 lines
1.1 KiB
Plaintext
# RUN: split-file %s %t
|
|
# RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown %t/chunk1.s -o %t/chunk1.o
|
|
# RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown %t/chunk2.s -o %t/chunk2.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/chunk1.o %t/chunk2.o -o %t/combined.wasm
|
|
# RUN: llvm-readobj --sections %t/combined.wasm | FileCheck %s
|
|
|
|
# Check that the linker doesn't crash with large data sections that together exceed 2GB.
|
|
# CHECK: Type: DATA (0xB)
|
|
# CHECK-NEXT: Size: 2348810260
|
|
|
|
# A 2GB + some extra bytes of data to make sure we go over 2G
|
|
#--- chunk1.s
|
|
.section .data.chunk1,"",@
|
|
.globl chunk1_start
|
|
.type chunk1_start,@object
|
|
chunk1_start:
|
|
.int32 0xAAAAAAAA
|
|
.int32 0xBBBBBBBB
|
|
.zero 2214592504
|
|
.int32 0xCCCCCCCC
|
|
.int32 0xDDDDDDDD
|
|
.size chunk1_start, 2214592512
|
|
|
|
#--- chunk2.s
|
|
.section .data.chunk2,"",@
|
|
.globl chunk2_start
|
|
.type chunk2_start,@object
|
|
chunk2_start:
|
|
.int32 0x11111111
|
|
.int32 0x22222222
|
|
.zero 134217712
|
|
.int32 0x44444444
|
|
.int32 0x55555555
|
|
.size chunk2_start, 134217728
|