· kaynak Hacker News – Front Page (native)
Microsoft destekli Call Graph Analyzer, monomorphize edilmiş MIR üzerinden Rust'taki panic yollarını haritalıyor
Tweede golf, Microsoft ile Open Device Partnership kapsamında çalışarak, derlenmiş bir ikili dosyada panic tetikleyebilecek fonksiyonları işaretlemek için Rust'ın monomorphize edilmiş MIR'sinden çağrı grafiğini çıkaran Call Graph Analyzer'ı yayınladı.

Microsoft ve Tweede golf, Rust için panic bulucu çıkardı
Rust danışmanlık şirketi Tweede golf, Microsoft ile Open Device Partnership kapsamında ortak geliştirilen Call Graph Analyzer (CGA) aracını geliştirdi ve yayınladı. Hacker News'in ana sayfasına ulaşan şirket blog yazısına göre araç, ekibin Rust geliştiricilerinden sıkça aldığı bir sorunu ele alıyor: kodlarından panic'leri nasıl çıkarabilirler.
CGA, generics somut türlere çözüldükten sonra Rust derleyicisinin ürettiği ara temsil olan monomorphize edilmiş MIR'den çağrı grafiğini çıkararak çalışıyor. Bu grafik, derlenmiş ikili dosyada fiilen yer alacak şeyi yansıttığı için, hangi fonksiyonların panic tetikleyebildiğini belirlemek üzere üzerinde dolaşılabiliyor. cargo cga check çalıştırmak bu yolları derleyici tarzı hatalar olarak ortaya çıkarıyor: yazı, u64 üzerindeki bir strict_sub çağrısını panic yeteneğine sahip olarak işaretleyen ve kaynak koddaki tam dosya, satır ve sütuna konumlandıran bir tanılamayı gösteriyor.
Peki panic'leri neden tamamen ortadan kaldırmalı
Yazıda açıklandığı gibi, Rust'taki panic, toparlanabilir olması beklenmeyen hata koşulları için dilin mekanizmasıdır; bu ya bir fonksiyon içindeki bir hata ya da çağıran tarafın giriş koşullarını ihlal etmesidir, örneğin katı aritmetik işlemlerini taştıran operandlar. Farklı davranış isteyen geliştiriciler, denetimli aritmetikle Result veya Option türleri döndürebilir, işlemlerin sessizce sarmasına izin verip bunu belgeleyebilir ya da daha az kullanışlı biçimde hiç dönmeyebilir.
Yazarlar, panic'leri tamamen ortadan kaldırmanın hem zor hem de büyük ölçüde yanlış bir hedef olduğu konusunda açık sözlü: kod nadiren varsayımlardan arîdir ve her başarısızlığı döndürülen bir hataya dönüştürmek, yükü yalnızca çağrı yığınında yukarı taşır; sonuçta kökte bir şey zaten iptal eder. Önerileri, panic yollarını açık hale getirmek, üzerinde bilinçli olarak kafa yormak ve yeni eklenen panic yollarının bir bildirim tetiklemesi için regresyon analizi çalıştırmak.
Yine de yazı, kaldırmanın haklı olduğu durumları da tanımlıyor. Gömülü cihazlarda panic biçimlendirme kodu ve ilişkili dizeleri ikili dosyaları şişirir; defmt::panic veya -Cpanic=immediate-abort gibi seçenekler boyut karşılığında hata ayıklanabilirliği takas eder. Asla başarısız olmaması gereken kod yollarında (bir çöküşün kendine inflik bir hizmet reddi demek olduğu internete açık bir servis veya bir cihazın firmware güncelleme ve bootloader yolu gibi) toparlanamaz bir panic kabul edilemez. Panic'ler ayrıca panic işleme mekanizmasının kendisinin içinde de sorunludur; bir Drop implementasyonu üzerinden geri sarma programı iptal edebilir ve özel bir #[panic_handler] içindeki panic ise hiçbir koşulda kabul edilmez. Bunların dışında yazarlar, en üst düzey toparlanma mekanizmaları öneriyor: gömülü cihazlarda watchdog timer'ları ve kurtarma imajları, host'larda ise uyarılarla birlikte catch_unwind.
Mevcut araçlarla karşılaştırması
Yazı önceki yaklaşımları inceliyor: ELF artefaktlarından DWARF hata ayıklama bilgisini madencilik yapan rustig ve findpanics; derleyicinin HIR'ine ve rust-analyzer'a dayanan, ikisi de cargo-callgraph adını taşıyan iki proje; bir MIR dışa aktarıcısı olan charon; ve linker tabanlı no-panic ile dont_panic crate'leri.
Tweede golf'a göre her birinin kör noktaları var. Linker hileleri yalnızca nihai ikili dosyada hiç panic yoksa panic'leri tespit edebilir ve kütüphanelerde çalışamaz. DWARF analizi, panic mekanizması inline edildiğinde veya bağlama sırasında kaybolduğunda bilgi kaybeder. HIR analizi yalnızca mevcut crate'i görür; bağımlılıkları, standart kütüphaneyi ve derleyici bayraklarına bağlı olarak kod üretiminin geç aşamalarında ortaya çıkan sınır denetimleri gibi derleyicinin yerleştirdiği kontrolleri kaçırır.
Yazarlara göre MIR tam doğru noktadır, çünkü optimizasyon herhangi bir şeyi kaldırmadan önce tüm bağımlılık kodunu, standart kütüphane dahil, görebilir. CGA'nın ona dayanmasının nedeni bu. Bedeli ise yanlış pozitifler: analiz, LLVM erişilemez kodu budamadan önce çalıştığı için araç, tam bir derlemenin ortadan kaldıracağı panic yollarını işaretleyebilir. Yazarlar yeni yaklaşımı, kullanım senaryosuna bağlı olarak, öncekilerden eşzamanlı olarak hem daha iyi hem daha kötü olarak konumlandırıyor.
Neden önemli
Panic'ler Rust'ın örtük başarısızlık kanalıdır ve çoğu ekip onları yalnızca testte veya üretimde tetiklendiğinde keşfeder. Derlenmiş programın tamamını, bağımlılıklar ve standart kütüphane dahil, statik olarak modelleyerek CGA; gömülü geliştiricilere, bootloader yazarlarına ve servis bakımcılarına, gönderimden önce başarısızlık yollarını denetleme imkânı sunuyor. Bilinen sınırlaması, yani muhafazakâr aşırı bildirim, sonuçların hâlâ insan incelemesi gerektirdiği anlamına geliyor; ama bu sürtünme, açıklanan hedefe tartışmalı biçimde hizmet ediyor: sıfır panic değil (yazarlar bunu gerçekçi dışı olarak nitelendiriyor), görünür, anlaşılmış ve zaman içinde izlenen panic yolları. Open Device Partnership kapsamında firmware yazan ekipler ve bir ikili dosyanın başarısızlık davranışını kayıt altına almak isteyen her Rust geliştiricisi için CGA, mevcut araç setine anlamlı bir katma.
- #rust
- #static-analysis
- #developer-tools
- #embedded
- #open-source