LLDB: CPU ve GPU Hatalarını Tek Oturumda Yakalamak

Yapay zeka iş yükleri tek bir işlemcide başlayıp bitmiyor. Üst seviye bir çatı (framework) üzerinde başlayan akış, çalışma sırasında yerel CPU kodları ile GPU üzerinde koşan çekirdekler (kernels) arasında sürekli gidip geliyor. Hata tam bu geçiş sınırında patladığında işler karışır. Sorunu çözmek için hem ana uygulamayı (host) hem de donanım tarafını (device) aynı anda görmen gerekir.

Geleneksel bir hata ayıklayıcıyı (debugger) başka bir sürece bağlamak bu sorunu çözmeye yetmiyor. Klasik araçlar, her sürecin tek bir mimariye ve tutarlı bir bellek görünümüne sahip olduğunu varsayar. Oysa CPU ve GPU tarafında işleyen kurallar bambaşkadır:

• Komut setleri ve mimari: Ana süreç x86-64 mimarisinde çalışırken, GPU çekirdekleri tamamen farklı bir komut seti kullanabilir.
• Yürütme modeli ve yazmaçlar (registers): CPU iş parçacıkları alışıldık yazmaç yapılarına sahipken, GPU'lar binlerce yürütme hattını (execution lanes) gruplar halinde eşzamanlı çalıştırır ve bu yapı klasik iş parçacığı modeline doğrudan oturmaz.
• Bellek alanları: İşaretçiler (pointers) farklı adres uzaylarını gösterir. Örneğin 0x1000 adresi, CPU sürecinde ve GPU sürecinde tamamen farklı bellek konumlarına karşılık gelebilir.

Tek Süreç Zorlaması Neden Tıkanıyor?#

Farklı iki dünyayı tek bir yapay süreç modeline sıkıştırmak hata ayıklayıcıyı gereksiz yere karmaşıklaştırır. Böyle bir birleştirmede aracın yapacağı her işlem, önce hedefin CPU mu yoksa GPU mu olduğunu çözmek zorunda kalır. Yazmaç yönetimi, bellek okumaları, kesme noktaları (breakpoints), adım adım ilerleme (stepping) ve durdurma olayları seçilen donanıma göre koşullu hale gelir. Bağımsız adres uzaylarını tek bir bellek haritasına zorlamak da cabasıdır.

Geçmişte donanım üreticileri bu engeli aşmak için AMD'nin ROCgdb'si veya NVIDIA'nın CUDA-GDB'si gibi cihaza özel hata ayıklayıcılar geliştirdi. Bu araçlar kendi platformlarına güçlü destek sunsa da ortak hata ayıklama yeteneklerinin her araçta ayrı ayrı yazılıp sürdürülmesini gerektiriyor.

LLDB-Server İçindeki Ortak Hızlandırıcı Mimarisi#

Meta mühendisleri ve hızlandırıcı alanındaki katılımcılar, LLDB için farklı bir yol seçti. Uygulamayı başlatmak, mevcut sürece bağlanmak ve düşük seviyeli hata ayıklama işlemlerini yürütmek için kullanılan lldb-server yardımcı sürecine, donanım üreticisinden bağımsız (vendor-neutral) bir hızlandırıcı eklenti mimarisi eklendi. LLDB istemcisi, bu sunucuyla GDB uzak protokolü (GDB remote protocol) üzerinden haberleşiyor.

Yeni mimari, CPU ve GPU arasındaki farkları gizlemek yerine onlara net bir sınır çiziyor. İki donanımı arka planda ayrı hata ayıklayıcı süreçleri olarak temsil ederken, geliştiriciye tek bir hata ayıklama oturumu sunuyor. Böylece paylaşılan hata ayıklayıcı altyapısı belirli bir GPU'ya bağımlı kalmıyor, donanım üreticileri de cihaza özgü davranışları yalnızca odaklanmış bir eklenti katmanında geliştirebiliyor. GPU'lar ana süreç içindeki bir çalışma zamanı (runtime) ve sürücü üzerinden kontrol edildiğinden, bu yapı cihaz hata ayıklamasının CPU ile koordineli yürümesini de sağlıyor.

Geliştirici İçin Pratik Çıkarımlar#

CPU ve GPU sınırını aşan uygulamalar geliştirirken hata ayıklama sürecine bakışını şu noktalarla güncelleyebilirsin:

• Adres uzaylarını ayrı düşün: Hata ayıklarken aynı bellek adresinin (örneğin 0x1000) ana süreçte ve cihazda farklı yerlere işaret edebileceğini hesaba kat. İşaretçi hatalarını incelerken verinin hangi bellek uzayında yaşadığını kontrol et.
• Koordinasyonu tek oturumda izle: GPU sürücü ve çalışma zamanı üzerinden CPU tarafından yönetildiği için, cihazdaki bir hatayı ararken ana süreçteki çağrı durumunu da aynı oturum içinde takip et.
• Araç katmanlarını tanı: LLDB kullanırken istemcinin GDB uzak protokolü üzerinden lldb-server ile konuştuğunu ve donanıma özgü işlemlerin hızlandırıcı eklentisiyle ayrıştırıldığını bilmek, çoklu mimari sorunlarını anlamlandırmanı kolaylaştırır.