wabt — The Binary Toolkit

นักพัฒนามักหยิบ WABT ขึ้นมาใช้เมื่อต้องแปลงไปมาระหว่าง .wat กับ .wasm, ตรวจสอบ binary ที่ compile มาจากเครื่องมืออื่นว่าเนื้อในมีอะไรบ้าง หรือ validate module ก่อน deploy จริง

wabt — WebAssembly Binary Toolkit — คือ reference implementation ของ WAT text format งานแปลง ตรวจสอบ หรือ validate ใดก็ตามที่เกี่ยวข้องกับ text ↔ binary boundary จะผ่านหนึ่งในสี่โปรแกรมหลักของตัวเอง

wat2wasm

wat2wasm คือ compiler หลัก ทำหน้าที่แยกวิเคราะห์ต้นฉบับ .wat, type-check และ emit binary .wasm ที่ถูกต้อง flags ที่มีประโยชน์ได้แก่ --debug-names (เก็บ annotation $name ไว้ใน name section ของ binary) และ --output / -o เพื่อควบคุมไฟล์ output

# การคอมไพล์พื้นฐาน
wat2wasm add.wat -o add.wasm

# เก็บ debug names ไว้ใน binary
wat2wasm add.wat --debug-names -o add.debug.wasm

# Validate เท่านั้น ไม่เขียน output
wat2wasm add.wat --no-check=false --output=/dev/null

wasm2wat

wasm2wat ทำ process ย้อนกลับ: อ่าน binary .wasm และ emit WAT text ที่อ่านได้ สิ่งนี้มีค่ามากเมื่อคุณต้องการตรวจสอบว่า compiler ระดับสูง (Emscripten, wasm-pack ฯลฯ) ผลิตอะไรออกมาจริงๆ

# Disassemble ไปยัง stdout
wasm2wat add.wasm

# Disassemble ไปยังไฟล์
wasm2wat add.wasm -o add.wat

# รวม source locations จาก DWARF section
wasm2wat add.wasm --generate-names

wasm-objdump

wasm-objdump แสดง metadata ที่มีโครงสร้างเกี่ยวกับไฟล์ .wasm — การจัดเรียง section, imports, exports และ function signatures — โดยไม่ต้องสร้าง WAT disassembly ทั้งหมด ใช้ -x สำหรับสรุปทั้งหมด หรือ -d เพื่อ disassemble เฉพาะ code section

# สรุป section ทั้งหมด
wasm-objdump -x add.wasm

# Disassemble code section เท่านั้น
wasm-objdump -d add.wasm

# แสดงเฉพาะ export section
wasm-objdump -j export add.wasm

ผลลัพธ์ -x โดยทั่วไปมีลักษณะดังนี้:

add.wasm:  file format wasm 0x1

Section Details:

Type[1]:
 - type[0] (i32, i32) -> i32
Function[1]:
 - func[0] sig=0
Export[1]:
 - func[0] <add> -> "add"
Code[1]:
 - func[0] size=7

wasm-validate

wasm-validate ตรวจสอบว่า binary เป็นไปตามข้อกำหนด WebAssembly โดยจะออกด้วย code 0 เมื่อสำเร็จและแสดง diagnostic เมื่อล้มเหลว ใช้ใน CI เพื่อตรวจจับ module ที่เสียหายหรือไม่ถูกต้องก่อนที่จะถึง production

# Validate โมดูล
wasm-validate add.wasm
# → add.wasm: OK

# Validate โมดูลพร้อม future proposal
wasm-validate --enable-threads shared.wasm

Run it — magic bytes และความยาว binary

สี่ไบต์แรกที่ offset 0 ของทุกไฟล์ .wasm ที่ถูกต้องคือ 00 61 73 6d — module magic (\0asm) runnable ด้านล่างคอมไพล์ module WAT ขั้นต่ำและแสดงทั้งความยาว binary และสี่ magic bytes เหล่านั้น

WebAssembly

const wat = `(module
  (func (export "add") (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add))`;
const bytes = await compileWat(wat);
console.log('Binary length:', bytes.length, 'bytes');
const magic = Array.from(bytes.slice(0, 4))
  .map(b => b.toString(16).padStart(2, '0'))
  .join(' ');
console.log('Magic bytes (offset 0):', magic);
console.log('Decoded magic:', String.fromCharCode(...bytes.slice(1, 4)));

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
`wasm-opt -Oz` (การ optimise เชิงรุกสุด หลัง `wat2wasm`)	ได้ size และ speed ที่ดีที่สุด	build time นานขึ้น และ binary ที่ได้ห่างไกลจาก `.wat` ต้นฉบับจน debug ยากขึ้น
เก็บ `--debug-names` ไว้ตอน `wat2wasm`	`wasm2wat`/`wasm-objdump` แสดงชื่อฟังก์ชันที่อ่านออกได้	เพิ่มขนาด binary ที่ต้อง ship ให้ผู้ใช้จริง

ข้อผิดพลาดที่พบบ่อย

คอมไพล์ .wat เป็น .wasm แล้ว ship ตรงๆ โดยไม่ผ่าน wasm-opt เลย พลาดการลดขนาดที่ได้มาแทบฟรีๆ
รัน wasm-validate หลังจาก deploy ไปแล้ว แทนที่จะ validate ทุก module ใน CI ก่อน ship เสมอ
เปิด --debug-names ทิ้งไว้ใน production build โดยไม่คิดเรื่อง trade-off ของขนาด binary ที่เพิ่มขึ้น

💡 ตัวอย่างจากของจริง

Emscripten เรียก wasm-opt ของ Binaryen ให้อัตโนมัติหลังขั้นตอนที่เทียบเท่ากับ wat2wasm เมื่อ build ด้วย -O2/-O3 ส่วนทีมที่ ship ไปที่ Cloudflare Workers/CDN มักใช้ wasm-validate เป็นด่านบังคับใน CI ก่อน deploy ทุกครั้ง