gccrs ile Linux derlemeye doğru ilerleme

• GCC için Rust ön ucu gccrs, 2026’nın ilk yarısında Linux çekirdeği crate’lerini test ederek öznitelik işleme, ad çözümleme ve kaynak yönetimi sorunlarını düzeltti; artık çekirdek kodunun doğru çalışma semantiğini uygulamaya odaklanıyor
• LLVM’in desteklemediği mimarilerden ve mevcut GCC eklenti ekosisteminden yararlanmak için GCC tabanlı bir Rust derleyicisi gerekiyor; bu, Linux dağıtımlarına araç zinciri seçeneği de sunabilir
• Doğru kod üretimi için kontrol akışına dayalı dinamik drop flag analizi gerekir; bunun atlanması MutexGuard’ın kilidi serbest bırakmamasına, dolayısıyla senkronizasyon hatasına veya deadlock’a yol açabilir
• Gerçek çekirdek crate’leri derlenirken Rust’ın üç namespace’ini yanlış ele alan ad çözümleme yapısı, #[cfg()] işleme sırası ve iç içe modülleri atlayan crate metadata sorunları ortaya çıktı; bu nedenle geniş kapsamlı yeniden çalışma yürütülüyor
• no_core programları ile core ve compiler_builtins desteğinde ilerleme kaydedildi, ancak çekirdeğin eksiksiz derlenmesi için alloc desteği ve doğru çalışma semantiği daha da gerekli; ayrıca GCC upstream entegrasyonu için inceleme ve koordinasyon da devam ediyor

---

Linux çekirdeğinin test hedefi olarak seçilme nedeni

• gccrs, GCC için bir Rust ön ucu geliştiren projedir; 2026’nın ilk yarısında Linux çekirdeğini derlemeye odaklandı
  • Çekirdek crate’lerini test ederken öznitelik işleme, ad çözümleme ve kaynak yönetimi sorunları bulundu ve düzeltildi
  • Şu anda yalnızca basit bağımsız programları işleyebiliyor, ancak çekirdek kodu testleri diğer Rust programları için doğru kod üretiminde de ilerleme sağlıyor
  • İlerleme, projenin haftalık raporlarında ve aylık raporlarında kaydediliyor
• Linux çekirdeğindeki mevcut Rust kodu LLVM tabanlı rustc kullanmak zorunda
  • rustc içinde GCC’yi backend olarak kullanan deneysel rust_codegen_gcc de geliştiriliyor
  • GCC tabanlı bir alternatif, LLVM’in hedeflemediği mimarileri desteklemek ve mevcut GCC eklenti ekosistemiyle entegre olmak için gerekli
  • Çekirdeğin Rust entegrasyonu olgunlaştıkça Linux dağıtımları araç zinciri esnekliğini ve GCC tabanlı derleyicinin kullanılabilirliğini öncelikli konu olarak görüyor

GCC sürümü yerine yeteneklere göre ayrılan kilometre taşları

• gccrs ekibi, Mart 2026 raporunda belirli bir GCC sürümünü hedeflemek yerine çalışma düzenini üç yetenek tabanlı kilometre taşına çevirdi
  • Gömülü Rust derleyicisi: Yalnızca core’a bağımlı no_std programlarını derler
  • Rust for Linux derleyicisi: core ve çekirdeğin kullandığı belirli crate’leri destekler
  • Genel amaçlı derleyici: Çekirdek ortamının ötesinde daha geniş Rust uygulamalarını işler
• İlk kilometre taşı henüz tamamlanmadı ama neredeyse ulaşıldı; Rust for Linux kilometre taşı üzerindeki çalışmalar da başladı
• Mart 2026’da çekirdek derlemesi için gereken düşük seviyeli crate compiler_builtins desteği eklendi ve çekirdeğin ffi crate’iyle ilgili sorunları çözmeye odaklanıldı
• Zhi Heng, Mayıs 2026’da Open Source Security stajı kapsamında katıldı
  • gccrs çekirdek crate’lerini derlerken ortaya çıkan hataları düzeltti
  • Regresyonları önlemek için sürekli entegrasyon testleri kurdu
• Rust kodunu çökmeden işlemek tek başına yeterli değil; üretilen kodun da doğru çalışması gerekiyor
  • İdyomatik Rust kodu C’ye göre destructor semantiğini daha fazla kullandığından, Drop uygulamaları doğru kod üretiminin merkezinde yer alıyor

Doğru kaynak serbest bırakma için Drop altyapısı

• Rust, kaynakları kaynak ediniminin başlatma olduğu RAII modeliyle yönetir; bir değer kapsam dışına çıktığında derleyici Drop trait içinde tanımlı destructor’ı otomatik çağırır
• Bir değişkenin başlatılma durumu, fonksiyon içindeki kontrol akışına göre değişebilir
  • Bir değer koşullu olarak taşınırsa veya yalnızca kısmen başlatılırsa kapsam sonunda koşulsuz olarak yok edilemez
  • Ön uç, kontrol akışı grafiğini analiz ederek bir değerin yok edilmesinin gerekip gerekmediğini çalışma zamanında kaydeden boolean değişkenler, yani dinamik drop flag’ler üretmeli ve bunları GCC backend’ine iletmelidir
• gccrs’in ilk Drop uygulamasında bu analiz yoktu; bu nedenle bazı Drop::drop() çağrıları atlandı veya hatalı üretildi
• Linux çekirdeğinde Drop çağrılarının atlanması, bellek sızıntıları ve sistem kaynaklarının geri verilmemesi gibi ciddi çalışma zamanı arızalarına yol açar
  • Kilit alındığında Rust for Linux API’si bir MutexGuard döndürür
  • Bu guard’ın Drop uygulaması kilidin serbest bırakılmasından sorumludur
  • Doğru Drop çağrısı olmazsa guard kapsam dışına çıksa bile kilit tutulmaya devam eder ve senkronizasyon hatası veya deadlock oluşabilir
• GSoC katılımcısı Janet Chien, Mayıs 2026’da katılarak gccrs’in Drop altyapısını kurmaya odaklandı

Rust namespace’lerine uygun ad çözümlemenin yeniden yazılması

• Standart kütüphane ve çekirdek crate testleri, gccrs’teki temel ad çözümleme hatalarını ortaya çıkardı
  • Proje birçok sorunun zaten farkındaydı ve 2023’ten beri ad çözümlemeyi ayrıca iyileştiriyordu
• Rust üç namespace’i ayırır
  • Değer namespace’inde fonksiyonlar ve statik değişkenler bulunur
  • Makro namespace’inde makrolar bulunur
  • Tip namespace’inde struct’lar, modüller ve trait’ler bulunur
• crate::foo::bar gibi yolları işlemek için her tanımlayıcı bölümünün hangi namespace’e ait olduğunu belirlemek gerekir
• Mevcut gccrs, sonunda bulunmak istenen öğenin türüne göre tüm yolu tek bir namespace içinde çözümlüyordu
  • Bir fonksiyon aranırken tüm yol bölümleri değer namespace’inde çözümleniyordu
  • Ancak modüller ve public import’lar tip namespace’inde olduğundan, fonksiyona ulaşmak için önce tip namespace’inde modül yapısını takip etmek gerekir
• Bunu düzeltmek için iç veri yapılarının yeniden yazılması ve kod genelindeki visitor uygulamalarının refactor edilmesi gerekti
  • Mayıs 2026’da core crate’indeki derin iç içe import’lar doğru çözümlenebilir hale geldi
  • Modül ve import’ların tip namespace’ine eklenmesiyle davranış rustc’ye daha da yaklaştı

Koşullu öznitelikler ve derleyici seçeneklerinde iyileştirmeler

• Çekirdek crate’lerini derleme sürecinde gccrs’in derleyici özniteliği işleme ve crate metadata sorunları da ortaya çıktı
• Rust, #[cfg()] gibi özniteliklerle koşullu derleme yapar
• Pierre-Emmanuel Patry, Şubat 2026’da öznitelik işleme pipeline’ını yeniden çalıştı
  • cfg öznitelikleriyle hariç bırakılan öğeleri kaldıran derleyici pass’ini iki aşamaya ayırdı
  • Çekirdeğin bazı kararsız özellikleri makro genişletmeye veya koşullu özniteliklere dayanır
  • Bu tür öznitelikler ana öznitelik doğrulama pass’inden önce kaldırılmalıdır; aksi halde doğrulama sırasında derleme hatası oluşur
• Mart 2026’da rustc’nin -Zcrate-attr seçeneğine karşılık gelen -frust-crate-attr seçeneği eklendi
  • Derleme sistemi, özgün kaynak dosyasını değiştirmeden derleyici çağrısı sırasında öznitelik enjekte edebilir
  • Standart core kütüphanesi olmadan kod derlemek için gereken #![no_core] aktarımında yararlıdır
  • Sınır durum hatalarını bulmak için derleyiciyi fuzz eden geliştiriciler de bu özelliği kullanır

Gerçek çekirdek kodunda ortaya çıkan metadata eksikleri

• Rust crate’leri genellikle başka crate’lere public API’yi aktarmak için .rlib dosyalarında yer alan metadata dışa aktarır
• Çekirdeğin Rust crate’lerini link’leme sürecinde, bazı modüllerin ve export’ların üretilen metadata’da eksik olduğu görüldü
  • gccrs, metadata üretimi sırasında iç içe modüllerin export’larını atlıyordu
  • Bunun sonucunda dış bağımlılıklar çözümlenemiyordu
• Mevcut metadata testleri düz modül yapıları kullandığından bu sorunu yakalayamadı; hata ancak gerçek kod derlendikten sonra ortaya çıktı
• GNU araç zinciriyle çekirdek bağımlılık ağacını link’leyebilmek için metadata işleme sistemi üzerinde büyük çaplı yeniden çalışma başlatıldı

Mevcut destek kapsamı ve GCC upstream kısıtları

• gccrs şu anda bağımsız no_core programlarını başarıyla işleyebiliyor
• core crate’ini işleme ve compiler_builtins uygulamasında da önemli ilerleme kaydedildi, ancak çekirdeğin karmaşık Rust soyutlamalarını tamamen derleme çalışması sürüyor
  • Çekirdek kodu parse edilebiliyor
  • Mevcut odak, çalışma zamanı semantiğini doğru uygulamak
• Teknik zorlukların yanında GNU araç zincirinin organizasyonel kısıtlarının da aşılması gerekiyor
  • Hızla değişen yeni bir dil ön ucunun tamamını GCC’ye entegre etmek büyük ölçekli bir iş
  • Büyük patch set’leri zaman zaman GCC upstream inceleme kapasitesinin sınırlarını aştı
  • Ön uç yapısı istikrara kavuştukça durum iyileşiyor
• Son dönemde 2 gccrs geliştiricisi GCC maintainer seviyesine yükseltildi
  • Kendi tree’lerinde güncellemeleri hazırlayıp ardından topluca yansıtabilir hale geldiler

alloc desteği ve gelecek sunumlar

• GSoC katılımcısı Enes Çevik, Mayıs 2026’da katılarak alloc crate’i desteğini uyguluyor
• alloc, Box, Rc, Vec gibi dinamik bellek ayırma tiplerinden sorumludur
  • Çekirdek geliştirme birçok standart kütüphane soyutlamasından kaçınsa da bazı temel Rust çekirdek soyutlamaları ayırma yapan tiplere dayanır
  • Bu nedenle alloc desteği Rust for Linux kilometre taşının zorunlu koşuludur
• Patry ve Arthur Cohen, 2026’nın ikinci yarısında Montreal’deki RustConf ve Barcelona’daki EuroRust etkinliklerinde “Compiling the Linux kernel with gccrs” sunumunu yapmayı planlıyor
• Çekirdek kodunun gerektirdiği özellikler sırayla uygulanarak, Linux çekirdeği ekosistemindeki Rust kodunu GCC ile derlemek için temel oluşturuluyor