ความคืบหน้าสู่การคอมไพล์ Linux ด้วย gccrs

• gccrs ฟรอนต์เอนด์ Rust สำหรับ GCC ได้ทดลองคอมไพล์ crate ของเคอร์เนล Linux ในช่วงครึ่งแรกของปี 2026 พร้อมแก้ปัญหาการจัดการ attribute, การ resolve ชื่อ และการจัดการทรัพยากร และตอนนี้กำลังมุ่งเน้นการทำ semantic การรันของโค้ดเคอร์เนลให้ถูกต้อง
• หากต้องการใช้สถาปัตยกรรมที่ LLVM ไม่รองรับและใช้ประโยชน์จาก ระบบนิเวศปลั๊กอิน GCC ที่มีอยู่ จำเป็นต้องมีคอมไพเลอร์ Rust บนฐาน GCC และยังช่วยให้ดิสโทร Linux มีทางเลือกด้าน toolchain มากขึ้น
• การสร้างโค้ดให้ถูกต้องจำเป็นต้องมี การวิเคราะห์ dynamic drop flag ตาม control flow หากขาดส่วนนี้ MutexGuard อาจไม่ปลดล็อก ทำให้เกิดความล้มเหลวในการซิงโครไนซ์หรือ deadlock ได้
• การคอมไพล์ crate ของเคอร์เนลจริงเผยให้เห็นปัญหาขนาดใหญ่ที่ต้องปรับแก้ใหม่ เช่น โครงสร้างการ resolve ชื่อที่จัดการ namespace ทั้งสามของ Rust ผิด, ลำดับการประมวลผล #[cfg()], และ metadata ของ crate ที่ตกหล่นโมดูลซ้อน
• การรองรับโปรแกรม no_core รวมถึง core และ compiler_builtins คืบหน้าแล้ว แต่การคอมไพล์เคอร์เนลอย่างสมบูรณ์ยังต้องมี การรองรับ alloc และ semantic การรันที่ถูกต้อง เพิ่มเติม รวมถึงยังเหลือการรีวิวและประสานงานเพื่อรวมเข้า upstream ของ GCC

---

เหตุผลที่ใช้เคอร์เนล Linux เป็นเป้าหมายทดสอบ

• gccrs เป็นโปรเจกต์พัฒนา ฟรอนต์เอนด์ Rust สำหรับ GCC โดยในช่วงครึ่งแรกของปี 2026 ได้มุ่งเน้นการคอมไพล์เคอร์เนล Linux
  • ระหว่างทดสอบ crate ของเคอร์เนล ทีมพบและแก้ปัญหาการจัดการ attribute, การ resolve ชื่อ และการจัดการทรัพยากร
  • ปัจจุบันยังจัดการได้เพียงโปรแกรมอิสระแบบง่าย ๆ แต่การทดสอบกับโค้ดเคอร์เนลก็ช่วยให้การสร้างโค้ดที่ถูกต้องสำหรับโปรแกรม Rust อื่น ๆ คืบหน้าไปด้วย
  • ความคืบหน้าถูกบันทึกไว้ใน รายงานรายสัปดาห์ และ รายงานรายเดือน ของโปรเจกต์
• โค้ด Rust ในเคอร์เนล Linux ปัจจุบันต้องใช้ rustc ที่อิง LLVM
  • ยังมีการพัฒนา rust_codegen_gcc แบบทดลอง ซึ่งใช้ GCC เป็น backend ใน rustc
  • ทางเลือกบนฐาน GCC จำเป็นต่อการรองรับสถาปัตยกรรมที่ LLVM ไม่ได้กำหนดเป็นเป้าหมาย และการผสานกับ ระบบนิเวศปลั๊กอิน GCC ที่มีอยู่
  • เมื่อการผสาน Rust เข้ากับเคอร์เนลสุกงอมขึ้น ดิสโทร Linux จึงให้ความสำคัญกับความยืดหยุ่นของ toolchain และความพร้อมใช้งานของคอมไพเลอร์บนฐาน GCC

แบ่ง milestone ตามความสามารถแทนเวอร์ชัน GCC

• ใน รายงานเดือนมีนาคม 2026 ทีม gccrs เปลี่ยนวิธีจัดงานจากการตั้งเป้าเป็นเวอร์ชัน GCC เฉพาะ มาเป็น milestone ตามความสามารถสามด้าน
  • คอมไพเลอร์ Rust สำหรับ embedded: คอมไพล์โปรแกรม no_std ที่พึ่งพาเฉพาะ core
  • คอมไพเลอร์ Rust for Linux: รองรับ core และ crate เฉพาะที่เคอร์เนลใช้
  • คอมไพเลอร์อเนกประสงค์: จัดการแอปพลิเคชัน Rust ได้กว้างขึ้นนอกเหนือจากสภาพแวดล้อมเคอร์เนล
• milestone แรกยังไม่เสร็จสมบูรณ์ แต่ใกล้ถึงแล้ว และงานสำหรับ milestone Rust for Linux ก็เริ่มขึ้นแล้ว
• ในเดือนมีนาคม 2026 ได้เพิ่มการรองรับ crate ระดับต่ำ compiler_builtins ที่จำเป็นต่อการ build เคอร์เนล และมุ่งแก้ปัญหา crate ffi ของเคอร์เนล
• Zhi Heng เข้าร่วมในเดือนพฤษภาคม 2026 ผ่านการฝึกงานกับ Open Source Security
  • แก้บั๊กที่เกิดขึ้นเมื่อ gccrs คอมไพล์ crate ของเคอร์เนล
  • สร้าง การทดสอบ continuous integration เพื่อป้องกัน regression
• แค่ทำให้โค้ด Rust ถูกจัดการโดยไม่ crash ยังไม่พอ โค้ดที่สร้างออกมาก็ต้องทำงานถูกต้องด้วย
  • โค้ด Rust แบบ idiomatic ใช้ semantic ของ destructor มากกว่า C ดังนั้นการ implement Drop จึงเป็นหัวใจของการสร้างโค้ดที่ถูกต้อง

โครงสร้างพื้นฐาน Drop เพื่อปล่อยทรัพยากรอย่างถูกต้อง

• Rust จัดการทรัพยากรด้วยโมเดล RAII ที่การได้มาซึ่งทรัพยากรคือการเริ่มต้นค่า และเมื่อค่าหลุดออกจาก scope คอมไพเลอร์จะเรียก destructor ที่นิยามไว้ใน Drop trait โดยอัตโนมัติ
• สถานะการ initialize ของตัวแปรอาจเปลี่ยนไปตาม control flow ภายในฟังก์ชัน
  • หากค่าถูก move แบบมีเงื่อนไขหรือถูก initialize เพียงบางส่วน จะไม่สามารถ drop แบบไม่มีเงื่อนไขที่ท้าย scope ได้
  • ฟรอนต์เอนด์ต้องวิเคราะห์ control-flow graph เพื่อสร้าง dynamic drop flag ซึ่งเป็นตัวแปร boolean ที่บันทึกใน runtime ว่าจำเป็นต้อง drop ค่าหรือไม่ แล้วส่งต่อให้ backend ของ GCC
• การ implement Drop ช่วงแรกของ gccrs ไม่มีการวิเคราะห์นี้ ทำให้การเรียก Drop::drop() บางส่วนตกหล่นหรือถูกสร้างผิด
• ในเคอร์เนล Linux การเรียก Drop ที่ตกหล่นนำไปสู่ความล้มเหลวร้ายแรงใน runtime เช่น memory leak และการไม่คืนทรัพยากรระบบ
  • เมื่อได้ lock มา Rust for Linux API จะคืน MutexGuard
  • การ implement Drop ของ guard นี้มีหน้าที่ปลดล็อก
  • หากไม่มีการเรียก Drop ที่ถูกต้อง แม้ guard จะหลุดออกจาก scope แล้ว lock ก็ยังคงอยู่ ทำให้เกิด ความล้มเหลวในการซิงโครไนซ์หรือ deadlock ได้
• Janet Chien ผู้เข้าร่วม GSoC เข้าร่วมในเดือนพฤษภาคม 2026 และมุ่งสร้างโครงสร้างพื้นฐาน Drop ของ gccrs

เขียนการ resolve ชื่อใหม่ให้ตรงกับ namespace ของ Rust

• การทดสอบกับไลบรารีมาตรฐานและ crate ของเคอร์เนลเผยให้เห็น บั๊กการ resolve ชื่อ พื้นฐานใน gccrs
  • โปรเจกต์ทราบปัญหาหลายอย่างอยู่แล้ว และได้แยกปรับปรุงการ resolve ชื่อมาตั้งแต่ปี 2023
• Rust แยก namespace ออกเป็นสามแบบ
  • namespace ของค่าประกอบด้วยฟังก์ชันและตัวแปร static
  • namespace ของ macro ประกอบด้วย macro
  • namespace ของ type ประกอบด้วย struct, module และ trait
• การจัดการ path เช่น crate::foo::bar ต้องตัดสินว่าแต่ละช่วงของ identifier อยู่ใน namespace ใด
• gccrs แบบเดิม resolve path ทั้งหมดใน namespace เดียวตามชนิดของ item สุดท้ายที่ต้องการหา
  • เมื่อค้นหาฟังก์ชัน จะ resolve ทุกช่วงของ path ใน namespace ของค่า
  • แต่ module และ public import อยู่ใน namespace ของ type ดังนั้นต้องไล่ตามโครงสร้าง module ใน namespace ของ type ก่อนจึงจะไปถึงฟังก์ชันได้
• เพื่อแก้ให้ถูกต้อง ต้องเขียนโครงสร้างข้อมูลภายในใหม่และ refactor การ implement visitor ทั่วทั้งโค้ด
  • ในเดือนพฤษภาคม 2026 สามารถ resolve import ที่ซ้อนลึกใน crate core ได้ถูกต้องแล้ว
  • เมื่อใส่ module และ import เข้าไปใน namespace ของ type พฤติกรรมก็ใกล้เคียงกับ rustc มากขึ้น

ปรับปรุง conditional attribute และตัวเลือกคอมไพเลอร์

• ระหว่างการคอมไพล์ crate ของเคอร์เนล ยังเผยให้เห็นปัญหา การจัดการ attribute ของคอมไพเลอร์ และ metadata ของ crate ใน gccrs
• Rust ใช้ attribute เช่น #[cfg()] เพื่อทำ conditional compilation
• Pierre-Emmanuel Patry ปรับ pipeline การจัดการ attribute ใหม่ในเดือนกุมภาพันธ์ 2026
  • แยก compiler pass ที่ลบ item ที่ถูกตัดออกด้วย attribute cfg เป็นสองขั้นตอน
  • ฟีเจอร์ unstable บางส่วนของเคอร์เนลพึ่งพา macro expansion หรือ conditional attribute
  • ต้องลบ attribute เหล่านี้ก่อน pass ตรวจสอบ attribute หลัก มิฉะนั้นจะเกิด error ระหว่างคอมไพล์ในขั้นตรวจสอบ
• ในเดือนมีนาคม 2026 ได้เพิ่มตัวเลือก -frust-crate-attr ซึ่งเทียบเท่ากับ -Zcrate-attr ของ rustc
  • ระบบ build สามารถ inject attribute ตอนเรียกคอมไพเลอร์ได้โดยไม่ต้องแก้ไฟล์ซอร์สต้นฉบับ
  • มีประโยชน์ในการส่ง #![no_core] ซึ่งจำเป็นต่อการคอมไพล์โค้ดโดยไม่มีไลบรารีมาตรฐาน core
  • นักพัฒนาที่ fuzz คอมไพเลอร์เพื่อหาบั๊กใน edge case ก็ใช้ฟีเจอร์นี้ด้วย

metadata ที่ตกหล่นซึ่งพบจากโค้ดเคอร์เนลจริง

• โดยทั่วไป Rust crate จะส่งออก metadata ที่อยู่ในไฟล์ .rlib เพื่อส่งต่อ API สาธารณะให้ crate อื่น
• ระหว่างการ link crate Rust ของเคอร์เนล พบว่าบาง module และ export หายไปจาก metadata ที่สร้างขึ้น
  • gccrs ทำ export ของ module ซ้อนตกหล่นระหว่างการสร้าง metadata
  • ส่งผลให้ไม่สามารถ resolve dependency ภายนอกได้
• การทดสอบ metadata เดิมใช้โครงสร้าง module แบบแบน จึงไม่พบปัญหานี้ และบั๊กเพิ่งปรากฏหลังคอมไพล์โค้ดจริง
• ทีมเริ่มปรับปรุง ระบบจัดการ metadata ครั้งใหญ่ เพื่อให้สามารถ link dependency tree ของเคอร์เนลด้วย GNU toolchain ได้

ขอบเขตการรองรับปัจจุบันและข้อจำกัดของ upstream GCC

• ปัจจุบัน gccrs สามารถจัดการโปรแกรม no_core แบบอิสระได้สำเร็จ
• การจัดการ crate core และการ implement compiler_builtins ก็คืบหน้าไปมากแล้ว แต่การคอมไพล์ abstraction Rust ที่ซับซ้อนของเคอร์เนลอย่างสมบูรณ์ยังอยู่ระหว่างดำเนินการ
  • สามารถ parse โค้ดเคอร์เนลได้
  • จุดเน้นปัจจุบันคือการ implement semantic ใน runtime ให้ถูกต้อง
• นอกจากโจทย์ทางเทคนิคแล้ว ยังต้องข้ามข้อจำกัดเชิงองค์กรของ GNU toolchain ด้วย
  • การรวมฟรอนต์เอนด์ภาษาใหม่ทั้งชุดที่เปลี่ยนแปลงเร็วเข้า GCC เป็นงานขนาดใหญ่
  • patch set ขนาดใหญ่บางครั้งเกินกำลังการรีวิวของ upstream GCC ที่มีจำกัด
  • เมื่อโครงสร้างฟรอนต์เอนด์เสถียรขึ้น สถานการณ์ก็ดีขึ้น
• ล่าสุดนักพัฒนา gccrs 2 คนได้รับการเลื่อนเป็น GCC maintainer
  • ทำให้สามารถเตรียมอัปเดตใน tree ของตนเองแล้วสะท้อนเข้าไปพร้อมกันได้

การรองรับ alloc และการนำเสนอในอนาคต

• Enes Çevik ผู้เข้าร่วม GSoC เข้าร่วมในเดือนพฤษภาคม 2026 และกำลัง implement การรองรับ crate alloc
• alloc รับผิดชอบ ชนิดข้อมูลที่จัดสรรหน่วยความจำแบบ dynamic เช่น Box, Rc, Vec
  • การพัฒนาเคอร์เนลหลีกเลี่ยง abstraction หลายอย่างของไลบรารีมาตรฐาน แต่ abstraction หลักบางส่วนของเคอร์เนล Rust พึ่งพา type ที่มีการจัดสรรหน่วยความจำ
  • ดังนั้นการรองรับ alloc จึงเป็นเงื่อนไขจำเป็นของ milestone Rust for Linux
• Patry และ Arthur Cohen วางแผนจะนำเสนอหัวข้อ “Compiling the Linux kernel with gccrs” ที่ RustConf ใน Montreal และ EuroRust ใน Barcelona ช่วงครึ่งหลังของปี 2026
• การ implement ฟีเจอร์ต่าง ๆ ที่โค้ดเคอร์เนลต้องการไปทีละขั้น กำลังสร้างรากฐานสำหรับการคอมไพล์โค้ด Rust ในระบบนิเวศเคอร์เนล Linux ด้วย GCC