Jonas Devlieghere
14d163e977
ObjectFileWasm hardcoded the architecture of every Wasm module as "wasm32-unknown-unknown-wasm". A Wasm binary does not actually encode a vendor or OS, those are properties of the runtime executing it. When debugging via a runtime whose gdb stub reports a more specific triple (e.g. WAMR reports "wasm32-wamr-wasi-wasm"), lldb adopts that triple and clears the module list. The dynamic loader then tries to reload the main executable, but GetOrCreateModule rejects the on-disk file because the triples are incompatible. This causes lldb to back to reading from memory. Fix all this by reporting a bare "wasm32"/"wasm64" architecture instead.
31 lines
730 B
YAML
31 lines
730 B
YAML
# RUN: yaml2obj %s -o %t
|
|
# RUN: lldb-test object-file %t | FileCheck %s
|
|
|
|
# CHECK: Plugin name: wasm
|
|
# CHECK: Architecture: wasm32
|
|
# CHECK: UUID:
|
|
# CHECK: Executable: false
|
|
# CHECK: Stripped: false
|
|
# CHECK: Type: shared library
|
|
# CHECK: Strata: user
|
|
# CHECK: Base VM address: 0x0
|
|
|
|
# CHECK: Name: code
|
|
# CHECK: Type: code
|
|
# CHECK: VM address: 0x0
|
|
# CHECK: VM size: 56
|
|
# CHECK: File size: 56
|
|
|
|
--- !WASM
|
|
FileHeader:
|
|
Version: 0x00000001
|
|
Sections:
|
|
- Type: CODE
|
|
Functions:
|
|
- Index: 0
|
|
Locals:
|
|
- Type: I32
|
|
Count: 6
|
|
Body: 238080808000210141102102200120026B21032003200036020C200328020C2104200328020C2105200420056C210620060F0B
|
|
|