- Modern Linux C/C++ geliştirme, optimize edilmiş ve standartlara uygun ikili dosyalar sunmak için GCC, Clang/LLVM ve IBM Open XL C/C++ gibi çözümlere dayanmaktadır.
- Linux'ta etkili hata ayıklama, yalnızca VS Code gibi editör entegrasyonlarına güvenmek yerine, GDB, IDE arayüzleri ve uygun DWARF hata ayıklama bilgilerini bir araya getirmeyi gerektirir.
- strace, ltrace, SystemTap ve core-dump iş akışları gibi araçlar, sistem çağrılarını, kütüphane etkileşimlerini ve ölüm sonrası durumu ortaya çıkararak GDB'yi tamamlar.
- Son GDB ve RHEL değişiklikleri, sağlamlığı, betik oluşturmayı ve bellek güvenliğini artırarak büyük ölçekli C/C++ hata ayıklamasını daha kontrol edilebilir ve öngörülebilir hale getiriyor.
Windows ve Visual Studio geçmişinden gelip birdenbire Linux üzerinde büyük bir C veya C++ kod tabanıyla çalışmaya başlarsanız, bu değişiklik oldukça zorlayıcı olabilir. VS Code gibi bir editörün arkasında GDB ile yüz binlerce satırı tek tek incelemek ve her adım için 30-60 saniye beklemek, acaba çok yanlış bir şey mi yapıyorsunuz yoksa Linux geliştirme süreci tasarım gereği mi yavaş diye düşünmenize neden olabilir. İyi haber şu ki, modern Linux araç zincirleri ve hata ayıklayıcıları son derece yeteneklidir; sadece bunları nasıl kuracağınızı ve hangi araçların büyük C/C++ projelerine uygun olduğunu bilmeniz yeterlidir.
Bu kılavuz, Linux'ta C/C++ derleyicileri, IDE'leri ve hata ayıklama araçları dünyasını size tanıtıyor., (görmek Linux'u sıfırdan öğrenin.GCC, Clang/LLVM ve IBM Open XL C/C++'dan GDB, Eclipse, SystemTap, strace, ltrace ve gelişmiş çekirdek dökümü iş akışlarına kadar birçok konuyu ele alacağız. Bu süreçte, klasik öğrenme ortamlarına (Geany + GCC gibi) da değinecek ve hata ayıklamayı hızlandırmak ve C ve C++ ile Linux geliştirmeyi Windows'ta alıştığınız rahatlığa çok daha yakın hale getirmek için somut ipuçları göstereceğiz.
Linux'ta C ve C++ için derleyiciler: GCC, Clang/LLVM ve IBM Open XL
Linux'ta C ve C++ için referans araç zinciri hala GCC'dir (GNU Derleyici Koleksiyonu) ve C++ ön ucu olarak g++ kullanılmaktadır. Çoğu dağıtım varsayılan olarak GCC'yi içerir ve neredeyse tüm eğitimler, derleme sistemleri ve CI işlem hatları onun varlığını varsayar. Genellikle şu komutlarla derleme yaparsınız: gcc C için ve g++ Örneğin C++ için g++ -g -O2 main.cpp -o app Hata ayıklanabilir, optimize edilmiş bir ikili dosya oluşturmak.
Clang ve LLVM ekosistemi, Linux'ta GCC'ye güçlü bir alternatif haline geldi.Hızlı derleme, mükemmel teşhis ve zengin bir araç seti (statik analiz, kod biçimlendirme, temizleyiciler ve daha fazlası) sunan Clang, çok sayıda mimariyi ve dili destekleyen ve geniş bir topluluk tarafından aktif olarak sürdürülen modüler bir açık kaynak derleyici altyapısı olan LLVM üzerine inşa edilmiş bir C/C++ ön uçtur.
IBM Open XL C/C++ for Linux on Power, Clang/LLVM'yi IBM'in uzun yıllara dayanan derleyici optimizasyon uzmanlığıyla sıkı bir şekilde entegre eden ticari bir araç zinciridir. IBM Power sistemlerini hedefleyen bu ürün, modern C/C++ dil özelliklerinden (C++17 dahil), standart LLVM optimizasyonlarından ve GCC ile uyumluluğundan yararlanarak Power donanımında yüksek performanslı ikili dosyalar sunar. Bu, LLVM ekosisteminin avantajlarından ve IBM tarafından geliştirilen platforma özel optimizasyonlardan faydalanacağınız anlamına gelir.
Eski sistemler için IBM, Linux için hala eski XL C/C++ derleyicilerini sunmaktadır.Bu sayede, mevcut derleme zincirlerine veya sertifikasyon kısıtlamalarına sahip kuruluşlar, yeni iş yükleri için Open XL C/C++'ı kademeli olarak benimserken bunları kullanmaya devam edebilirler.
Klasik öğrenme ortamı: GCC ve hafif IDE'ler
Linux üzerinde C veya C++ ile yeni başlıyorsanız, çok yaygın ve etkili bir kurulum GCC ve Geany gibi hafif bir IDE'den oluşur. Geany, platformlar arası (Linux ve Windows) çalışır, hızlıdır ve proje yönetimi, derleme komutları ve basit hata ayıklama gibi temel özellikleri, kapsamlı ve ağır IDE'lerin getirdiği ek yük olmadan entegre eder.
Linux için hazırlanan birçok uzun soluklu C/C++ kursu, tam olarak bu kombinasyonu önermektedir: Derleyici olarak GCC ve geliştirme ortamı olarak Geany. Bu tür eğitimler sayesinde genellikle dili temelden öğrenirsiniz: GNU derleyicisinin ne olduğunu ve nasıl çağrılacağını, bir programın nasıl yapılandırılacağını, koşullu ifadelerle, fonksiyonlarla, dizilerle, dizelerle, işaretçilerle, yapılarla, birleşimlerle, dosya giriş/çıkışıyla ve nihayetinde C++'da kalıtım, operatör aşırı yüklemesi ve polimorfizm gibi nesne yönelimli kavramlarla nasıl çalışılacağını öğrenirsiniz.
IDE seçimleri farklılık gösterse de, temel araç zinciri tavsiyesi genellikle tutarlıdır: mümkün olduğunca tüm platformlarda GCC (veya g++) kullanın. Linux'ta bu varsayılan ayardır; Windows ve macOS'ta ise GCC'yi MinGW, MSYS2, WSL, Homebrew veya benzeri araçlar aracılığıyla kurarak sistemler arasında tek tip bir iş akışı sağlayabilir ve komut dosyaları ile Makefile'ları paylaşmayı kolaylaştırabilirsiniz.
Bir IDE derleme adımlarını soyutlasa bile, bunun sadece bir çağrı olduğunu anlamak önemlidir. gcc or g++ Karmaşık derleme veya çalışma zamanı sorunlarının giderilmesi için perde arkası işlemler çok önemlidir. Gibi seçenekler -g hata ayıklama bilgileri için, optimizasyon seviyeleri gibi -O0, -O2 or -O3ve uyarıları veya standartlara uygunluğu ayarlamak için bayraklar (-Wall, -std=c++17(vb.) Tüm bunlar, ince hataları teşhis ederken büyük önem taşır.
Büyük C++ kod tabanlarında hata ayıklama: VS Code'dan yerel GDB'ye
Windows'ta Visual Studio'dan Linux'a geçiş yapan geliştiriciler genellikle Visual Studio Code ve GDB tabanlı bir eklentiyle başlarlar ve büyük arka uçlarda hata ayıklayıcıda adım adım ilerlemenin son derece yavaş hale geldiğini kısa sürede fark ederler. Yüz binlerce satırdan ve birçok arka uç bileşeninden oluşan büyük belge işleme veya dağıtım sistemlerinde hata ayıklama sırasında her adımda 30-60 saniyelik gecikmeler yaşanması alışılmadık bir durum değildir.
Bu yavaşlık genellikle GDB'nin kendisinin bir sınırlaması değil, VS Code ile altta yatan hata ayıklayıcı arasındaki entegrasyon katmanının veya yapılandırmanın bir sonucudur. Hata ayıklama uzantısındaki sorunlar, kesme noktalarının nasıl senkronize edildiği, sembol bilgilerinin nasıl yüklendiği ve MI (Makine Arayüzü) komutlarının nasıl çevrildiği gibi faktörler, karmaşık gerçek dünya uygulamalarında büyük yavaşlamalara katkıda bulunabilir.
VS Code C/C++ uzantısında, Linux'ta GDB ile adım adım ilerleme performansıyla ilgili uzun süredir devam eden sorunlar olduğu biliniyor. Bazı ekipler için bu, VS Code'un harika bir editör olduğu ancak devasa C++ servislerinde hata ayıklama için en hızlı ön uç seçeneği olmadığı anlamına gelir; alternatifler arasında şunlar yer alır: Google Antigravity IDE Ayrıca yerel IDE'ler de mevcuttur. Performans kritik olduğunda, birçok mühendis doğrudan GDB'yi kullanmaya veya yerel araç zinciriyle daha derinlemesine entegre olmuş yerel bir IDE'ye geçmeye yönelir.
Dolayısıyla, Linux'ta VS Code hata ayıklama oturumunuzdaki her adımın yarım dakika sürdüğünü fark ederseniz, Linux hata ayıklamasının doğası gereği bu kadar yavaş olduğunu varsaymayın. Pes etmeden önce, GDB'yi aynı ikili dosya üzerinde doğrudan bir terminalde test edip davranışlarını karşılaştırmak faydalı olacaktır. Genellikle, GDB içinde adım adım ilerlemek çok daha hızlıdır; bu da temel bir işletim sistemi veya derleyici sorunundan ziyade bir yapılandırma veya uzantı darboğazına işaret eder.
Linux kullanan büyük C++ şirketlerinde, rahat hata ayıklama için popüler alternatifler arasında CDT (C/C++ Geliştirme Araçları) ile Eclipse, CLion, Qt Creator, KDevelop ve GDB ile yerel sistemle daha sıkı entegre olan diğer yerel IDE'ler yer almaktadır. Bu ortamlar, dil bağımsız hata ayıklama katmanlarının ek yükü olmadan, arka planda GDB'yi kullanırken kaynak kodunda gezinme, izleme pencereleri ve zengin kesme noktaları sağlayabilir.
Linux'ta hata ayıklama bilgileri: ELF, DWARF, debuginfo ve debugsource
Linux'ta derlenmiş programlar ve paylaşımlı kütüphaneler genellikle ELF (Executable and Linkable Format) dosyalarında saklanır ve bunlarla ilişkili hata ayıklama bilgileri DWARF formatında kodlanır. DWARF, hata ayıklayıcıların makine kodunu kaynak dosyalara, satır numaralarına, fonksiyonlara, türlere ve değişkenlere eşlemek için ihtiyaç duyduğu meta verileri içerir.
ELF ikili dosyasındaki DWARF bölümlerini aşağıdaki gibi araçlarla inceleyebilirsiniz. readelf -w fileBu komut, ham hata ayıklama kayıtlarını görüntüler. DWARF'ı genellikle manuel olarak okumazsınız, ancak bu, hata ayıklama bilgilerinin mevcut olup olmadığını doğrular ve GDB veya diğer araçlarda "sembol yüklenmedi" türündeki sorunların teşhisinde paha biçilmez olabilir.
STABS adı verilen daha eski bir hata ayıklama formatı hala mevcut olsa da, Red Hat Enterprise Linux gibi modern Linux dağıtımlarında eskimiş kabul ediliyor ve kullanımı önerilmiyor. GCC ve GDB, STABS için en iyi çabayı gösteren desteği sunar, ancak ekosistemdeki temel araçlar (örneğin Valgrind veya elfutils) onunla doğru şekilde çalışmayabilir; bu nedenle DWARF şiddetle tavsiye edilir.
Hata ayıklama verileri genellikle büyük boyutlu olduğundan, çoğu dağıtım bu verileri ana ikili dosyalardan ayırarak debuginfo ve debugsource adlı ayrı paketlere yerleştirir. Varsayılan depodan yüklediğiniz yürütülebilir dosya, disk alanından tasarruf etmek ve bellek kullanımını azaltmak için genellikle hata ayıklama sembollerinden arındırılmıştır; ilgili debuginfo paketi DWARF verilerini içerir ve isteğe bağlı olarak debugsource paketi de eşleşen kaynakları içerir.
RHEL ve benzeri sistemlerde, derleme sırasında hata ayıklama bilgilerini açıkça şu şekilde talep edersiniz: -g GCC ile kendi projelerinizi oluştururken. Paketlerden yüklenen sistem ve üçüncü taraf kütüphaneleri için ilgili bilgilere ulaşabilirsiniz. debuginfo hem de debugsource GDB, hata ayıklama oturumu sırasında eksik sembolleri fark ettiğinde genellikle doğrudan ipucu verdiği, özel hata ayıklama depolarından gelen paketler.
Sistem ikili dosyaları için hata ayıklama bilgilerini yükleme ve bulma
Sistem kütüphanelerine bağımlı C veya C++ programlarında hata ayıklama yaparken, bu kütüphaneler için debuginfo'nun kurulu olması, geri izlemelerin ve değişken incelemesinin kalitesinde çok büyük bir fark yaratabilir. Onsuz, paylaşımlı kütüphanelerde yalnızca ham adresler veya bozulmuş fonksiyon adları görürsünüz; onunla birlikte, satır bazında yığın izleri ve sembolik değişken adları elde edersiniz.
RHEL benzeri dağıtımlarda, GNU Hata Ayıklayıcı (GDB), yüklenen bir nesne için hata ayıklama bilgisinin eksik olduğunu otomatik olarak algılayabilir ve gerekli bilgileri yüklemek için somut bir komut önerebilir. debuginfo aracılığıyla paket dnf. Önerilen komutu çalıştırmanız yeterli. dnf debuginfo-install ... Komutu girin, istendiğinde onaylayın ve sistem oturumunuz için gerekli sembol paketlerini indirip kuracaktır.
Otomatik ipuçları mevcut değilse, ikili dosyayı veya kütüphane dosyasını aşağıdaki gibi araçlarla bularak gerekli hata ayıklama bilgilerini manuel olarak belirleyebilirsiniz. locate ve ardından RPM veritabanını sorgulamak. MKS locate komut şuradan geliyor mlocate Bu paketi yüklemeniz ve başlatmanız gerekebilir; yolunu öğrendikten sonra, hangi paketin ona sahip olduğunu sorabilir ve ardından ilgili debuginfo varyantını yükleyebilirsiniz.
Bazı durumlarda, belirli bir ikili dosyayı hangi paketin yüklediği belirlenemez; örneğin, dosya manuel olarak kopyalandığında veya paketleme yapılmadan yerinde derlendiğinde. Bu durumlarda, özel sembol dosyalarına geri dönmeniz veya mümkünse ikili dosyayı kendiniz yeniden derlemeniz gerekebilir. -g GDB'nin tüm hata ayıklama verilerine erişebilmesi için etkinleştirildi.
Unutmayın ki, sistemdeki her bir kütüphane için hata ayıklama bilgisi yüklemek nadiren gereklidir ve israf olabilir. Sorununuzla en alakalı modüllere odaklanın: tüm işletim sistemi için hata ayıklama paketleri indirmek yerine, uygulamanızın ikili dosyalarına ve çökmenin veya hatalı davranışın kaynaklandığı belirli kütüphanelere yoğunlaşın.
Linux'ta etkileşimli hata ayıklama için GDB kullanımı
GDB, Linux üzerinde yerel C ve C++ uygulamalarında hata ayıklama için kullanılan merkezi bir araçtır ve hem komut satırı arayüzü hem de entegrasyonlar aracılığıyla Eclipse CDT gibi grafiksel ön uçlar sunar. Red Hat Enterprise Linux'te standart dağıtım, isteğe bağlı grafik arayüzleriyle birlikte tam özellikli GDB'yi içerir.
Bir programı baştan hata ayıklamak için genellikle şu komutu kullanırsınız: gdb ./programGerektiği gibi kesme noktaları yapılandırın, ardından GDB içinde yürütmeyi başlatın. run Komut. Alternatif olarak, halihazırda çalışan bir programa şu şekilde bağlanabilirsiniz: gdb -p <pid> veya GDB'yi başlatarak ve şunu kullanarak attach Komutu işlem kimliğiyle birlikte verin.
GDB, bağlantı sırasında belirli bir PID için hedef yürütülebilir dosyayı çıkaramazsa, hangi ikili dosyayı kullanacağını açıkça belirtebilirsiniz. file komutu verin ve ardından hata ayıklamaya devam edin. Bu özellik, özellikle gerçek yürütülebilir dosya yolunun açık olmadığı özel başlatıcılar, sarmalayıcı komut dosyaları veya çoklu ikili dosya kurulumlarıyla uğraşırken oldukça kullanışlıdır.
Program bağlandıktan veya başlatıldıktan sonra, program akışını aşağıdaki gibi komutlarla kontrol edersiniz. n (Sonraki), s (adım), until, finish ve basitçe c (devam et), hata ayıklayıcıdan çıkarken q bittiğinde. Bu komutların her birinin, fonksiyon gövdelerine girip girmeyeceği, belirli bir satıra kadar çalışıp çalışmayacağı veya bir sonraki kesme noktasına veya sonlandırmaya kadar yürütmeye devam edip etmeyeceği konusunda belirli anlamları vardır.
Durumu anlamak için GDB, değişkenleri, çağrı yığınlarını, kayıtları ve daha fazlasını incelemek üzere zengin iç gözlem komutları sunar ve ayrıca bağlamsal yardım da sağlar. help info ve benzer komutlar. Mevcut kaynak satırını şu şekilde gösterebilirsiniz: listDeğişkenleri yazdırın printYığın çerçevelerini keşfedin backtrace ve çerçeveler arasında gezinmek için frame, up hem de down.
GDB'de kesme noktaları, izleme noktaları ve koşullar
Gerçek dünyadaki hata ayıklama işlemlerinde, neredeyse hiçbir zaman körü körüne bir adım atmazsınız. main()Bunun yerine, programın davranışının ilginç hale geldiği noktada programı durdurmak için stratejik olarak kesme noktaları yerleştirirsiniz. Standart komut break Bu özellik, dosya ve satır numarasına veya fonksiyon adına göre kesme noktaları belirlemenize olanak tanır ve GDB, bir sonraki isabette yürütmeyi durdurur.
Örneğin, aşağıdaki gibi bir sözdizimi kullanarak belirli bir kaynak satırına kesme noktası koyabilirsiniz. break file.cpp:123veya bir fonksiyonun başlangıcında kesme işlemi yapın. break my_function. Kesme noktasına ulaşıldığında, GDB programı durdurur ve yerel değişkenleri incelemenize, çağrı yığınını kontrol etmenize ve bir sonraki adıma geçmeye, bir sonraki adıma atlamaya veya devam etmeye karar vermenize olanak tanır.
Bir hata yalnızca birçok yinelemeden sonra veya belirli giriş değerleri altında ortaya çıktığında, koşullu kesme noktaları son derece değerlidir. C veya C++ dilinde yazılmış bir Boolean koşulunu bir kesme noktasıyla ilişkilendirebilirsiniz; böylece GDB yalnızca koşul doğru olduğunda durur, bu da gereksiz duraklamaları önemli ölçüde azaltır ve döngülerin veya karmaşık durum makinelerinin hata ayıklamasını çok daha verimli hale getirir.
Kod akışındaki değişiklikleri değil, verilerdeki değişiklikleri izlemek için GDB, bir ifadeden (genellikle bir değişkenden) okuma veya yazma işlemi yapıldığında tetiklenen izleme noktaları sunar. Şu gibi komutlarla watch, rwatch (oku) veya awatch (Okuma/yazma) özelliği sayesinde, belirli bir alan değiştirildiğinde veya erişildiğinde yürütmeyi tam olarak durdurabilirsiniz; bu, özellikle beklenmedik durum değişikliklerini izlemede faydalıdır.
Kesme noktaları ve izleme noktalarının tümünü aşağıdaki gibi komutlar aracılığıyla yönetirsiniz: info breakpoints or info brAyrıca, numara veya konuma göre silme işlemini gerçekleştirebilirsiniz. delete uygun argümanlarla. Bu sayede aktif kesme noktalarının düzenli bir şekilde tutulması kolaylaşır ve birden fazla modül veya oturumda hata ayıklama sırasında karışıklığın önüne geçilir.
Çoklu iş parçacıklı ve çatallanmış süreçlerin hata ayıklaması
Çok sayıda iş parçacığı veya fork kullanan C ve C++ programlarında hata ayıklama, GDB'nin yürütme bağlamlarını nasıl izlediği konusunda ek bir farkındalık gerektirir. Varsayılan olarak, GDB geçerli bir iş parçacığı belirler ve çoğu komut, siz açıkça geçiş yapmadığınız sürece bu iş parçacığında çalışır. thread ve iş parçacığı tanımlayıcısı.
Programınız çatallandığında, ayar set detach-on-fork GDB'nin alt süreci mi yoksa üst süreci mi takip edeceğini ve takip edilmeyen süreci nasıl ele alacağını belirler. GDB'yi, analiziniz için ana, alt veya her ikisinin de önemli olup olmadığına bağlı olarak, her ikisini de kontrol altında tutacak veya bir taraftan otomatik olarak ayrılacak şekilde yapılandırabilirsiniz.
Daha yeni GDB sürümleri, uyumluluk için ayrı bir genel iş parçacığı kimliğinin yanı sıra alt iş parçacığı başına bir kimlik de ekleyerek iş parçacıklarının numaralandırılma biçimini geliştirdi. Kolaylık değişkeni $_thread ve Python API'lerinin InferiorThread.num Artık alt kademeye özel numaralandırma yansıtılıyor, küresel tanımlayıcı ise şu yolla erişilebilir: $_gthread hem de InferiorThread.global_numBu sayede, küresel kimliklere dayalı eski araçların çalışmaya devam etmesi sağlanır.
Çoklu iş parçacıklı hata ayıklamada sinyal işleme de iyileştirildi, böylece sinyaller her zaman doğru iş parçacığına iletilir. Bir sinyal programı durdurduktan sonra iş parçacığını değiştirirseniz ve ardından devam etmeye çalışırsanız, GDB onay isteyebilir; bu da yanlışlıkla yanlış iletimi önler ve sinyalle ilgili hata ayıklamayı daha güvenilir hale getirir.
Tüm bunlar, kilitlenmeleri, yarış durumlarını veya garip sinyal tetiklemeli çökmeleri analiz ederken, GDB'nin iş parçacığı modeline güvenerek doğru yürütme yolunu hassas bir şekilde takip edebileceğiniz anlamına gelir. Kesme noktaları, izleme noktaları ve yakalama noktalarıyla birlikte kullanıldığında, bu özellik yüksek eşzamanlılık gerektiren C++ servislerinde bile sağlam çoklu iş parçacıklı hata ayıklama olanağı sağlar.
Sistem ve kütüphane çağrılarını izleme: strace, ltrace ve SystemTap
Bazen bir C veya C++ programının neden hatalı davrandığını anlamanın en hızlı yolu, her satırı tek tek incelemek değil, programın işletim sistemi ve paylaşımlı kütüphaneleriyle nasıl etkileşim kurduğunu gözlemlemektir. Linux bu iş için çeşitli güçlü araçlar sunar: strace, ltrace, SystemTap ve hatta özel yakalama noktaları aracılığıyla GDB'nin kendisi.
MKS strace Bu yardımcı program, sistem çağrılarını (çekirdekle olan etkileşimler gibi) izler. open, read, write, mmap, execve ve bu böyle devam eder; parametreleri ve dönüş değerleriyle birlikte. Programınızı şu şekilde çalıştırabilirsiniz: strace veya PID kullanarak çalışan bir işleme bağlanabilir, isteğe bağlı olarak görüntülenecek sistem çağrılarını aşağıdaki gibi ifadeler kullanarak filtreleyebilirsiniz. -e trace=call ve çatallı mı yoksa iplikli çocukları mı takip edeceğine karar vermekle -f.
Gerçek uygulamalar çok sayıda sistem çağrısı yaptığı için, birleştirme işlemi... strace kabuk araçlarıyla tee Çıktıyı hem canlı olarak görüntülemek hem de analiz için saklamak yaygın bir uygulamadır. Bu, eksik dosyaları, izin sorunlarını, beklenmedik ağ davranışlarını veya kodun kendisinden anlaşılamayabilecek diğer işletim sistemi düzeyindeki sorunları belirlemenize yardımcı olur.
strace'i tamamlayıcı nitelikte, ltrace Kullanıcı alanındaki paylaşımlı kütüphane fonksiyonlarına yapılan çağrılara odaklanır ve dinamik nesnelerden dışa aktarılan fonksiyonların çağrılarını ve dönüş değerlerini gösterir. RHEL 8'de ltrace'in belirli sistem yürütülebilir dosyalarını izleyememesi gibi bilinen bir sınırlama vardır, ancak kullanıcı tarafından oluşturulan ikili dosyalar için normal şekilde çalışır; bu da programınızın kütüphane API'lerini nasıl kullandığını anlamak için değerli bir araç haline getirir.
SystemTap, kendi betik dilini kullanarak hem çekirdek hem de kullanıcı alanı olayları için özel olay işleyicilerine olanak tanıyan daha gelişmiş bir izleme çerçevesidir. strace veya ltrace'e göre kullanımı daha karmaşık olabilir ancak daha iyi ölçeklenebilir ve gelişmiş filtreleme ve toplama işlemlerini destekler. Kolaylık sağlamak için, örnek bir komut dosyası aşağıda verilmiştir. strace.stp SystemTap ile birlikte gelen bu yazılım, SystemTap'in altyapısını kullanarak strace benzeri davranışları taklit eder.
GDB, sistem çağrıları ve sinyaller için yakalama noktaları kullanarak, aşağıdaki gibi komutlar aracılığıyla izleme işlemine kendisi de katılabilir. catch syscall hem de catch signal. Bu ayarlar, program belirli sistem çağrıları yaptığında veya belirli sinyaller aldığında hata ayıklayıcının yürütmeyi durdurmasına neden olur; bu da etkileşimli hata ayıklama sırasında hassas kontrol gerektiğinde çok kullanışlı olabilir.
GDB ile çekirdek dökümleri ve ölüm sonrası hata ayıklama
Bir C veya C++ uygulaması etkileşimli olarak yeniden üretilmesi zor bir şekilde çöktüğünde veya donduğunda, çekirdek dökümleri kritik anda belleğin ve durumun anlık bir görüntüsünü sağlar. Çekirdek dökümü, bir işlemin sonlanması sırasında işlemcinin bellek bölümlerinin (yığın, öbek, eşlemeler) içeriğini içeren bir ELF dosyasıdır ve bunu daha sonra GDB ile, sanki çökme anında sisteme bağlıymışsınız gibi analiz edebilirsiniz.
Çekirdek dökümlerini etkili bir şekilde kullanmak için, bunların gerçekten oluşturulduğundan ve kaynak sınırlamaları veya yapılandırma tarafından engellenmediğinden emin olmalısınız. Shell'in limitleri gibi ulimit -c Çekirdek dosyalarının oluşturulmasını engelleyebilir; sınırı şu şekilde ayarlamak: unlimited Boyut sınırlamalarını kaldırır, ancak üretim sistemlerinde disk alanı üzerindeki etkilerini gözden geçirmeniz gerekir.
Modern RHEL sistemlerinde, systemd-coredump Çekirdek dökümlerini şeffaf bir şekilde yönetir ve bunları merkezi, günlük benzeri bir konumda saklar. core Dosyalar farklı dizinlere dağılmış durumda. MKS coredumpctl Bu araç, kaydedilen çökmeleri listelemenize, meta verilerini incelemenize ve daha derinlemesine analiz için gerçek çekirdek dosyasını seçtiğiniz bir yola dışa aktarmanıza olanak tanır.
Sistematik bir kaza yakalama iş akışı oluştururken, genellikle aşağıdaki yazılımların yüklenmesi tercih edilir: sos paketle ve kullan sosreport Sistem yapılandırması ve günlükleri içeren bir tarball dosyası oluşturmak. Dışa aktarılan çekirdek dosyası ve uygulama ikili dosyalarıyla birlikte, bu size çökmeleri ayrı bir makinede analiz etmek veya başka bir ekibe veya tedarikçiye devretmek için gereken her şeyi sağlar.
Hatta yanıt vermeyen bir işleme iptal sinyali göndererek veya aşağıdaki gibi araçlar kullanarak kasıtlı olarak çekirdek dökümü tetikleyebilirsiniz. gcoreBu komut, işlem hala çalışırken işlem belleğini boşaltır. Bir sırasında gcore "Dump" komutu çalıştırıldığında, işlem kısa bir süre duraklıyor, ardından normal çalışmasına devam ediyor; bu sayede hizmeti tamamen sonlandırmadan sorunlu bir durumun çevrimdışı analizi yapılabiliyor.
Çekirdek analizi için doğru yürütülebilir dosyayı ve sembolleri bulmak
Bir çekirdek dökümünü anlamlı bir şekilde analiz etmek için GDB'nin hem çekirdek dosyasına hem de onu üreten tam yürütülebilir dosyaya (ve ilgili paylaşımlı kütüphanelere) ihtiyacı vardır. Bu önemlidir çünkü farklı sürümlerden oluşturulmuş uyumsuz ikili dosyalar, yanıltıcı hata izleme kayıtlarına ve hatalı değişken düzenlerine yol açabilir.
Gibi araçlar coredumpctl info Yakalanan her bir çekirdek için, ana yürütülebilir dosyanın yolunu ve ikili dosyayı benzersiz şekilde tanımlayan bir derleme kimliğini içeren ayrıntılı meta verileri gösterin. Derleme kimliği uzun bir onaltılık karma sayı gibi görünebilir ve GDB'yi başlatmadan önce aynı olduklarından emin olmak için bunu ikili dosyanın yerel kopyasının derleme kimliğiyle karşılaştırabilirsiniz.
Çalıştırılabilir dosya ve kütüphaneleri RPM paketlerinden geliyorsa, şunları kullanabilirsiniz: sosreport ve gerekli olan tam sürümleri almak için paket veritabanı. Bazı durumlarda, ilgili paketleri özel bir hata ayıklama makinesine yeniden yükleyebilir ve ardından GDB'nin özelliklerini kullanabilirsiniz. set sysroot Uzaktan hata ayıklama için yansıtılmış bir kütüphane düzenine işaret edecek şekilde yapılandırma.
Gerekli nesnelere sahip olduktan sonra, aşağıdaki gibi bir komutla bir GDB oturumu başlatabilirsiniz: gdb /path/to/exe /path/to/core ve GDB'nin çekirdeği yüklemesine izin verin. Herhangi bir modül için hata ayıklama bilgisi eksikse, GDB, sembollerin tam görünürlüğünü elde etmek için hangi paketleri veya sembol dosyalarını yüklemeniz gerektiğine dair ipuçları içeren mesajlar görüntüler.
Uygulamanızın hata ayıklama sembolleri paketler yerine ayrı dosyalarda sağlanıyorsa, bunları aşağıdaki komutu kullanarak açıkça yükleyebilirsiniz: symbol-file GDB içindeki komut. Çekirdekteki her bir paylaşımlı kütüphane için hata ayıklama bilgisine sahip olmak zorunda değilsiniz; genellikle kendi uygulamanıza ve şüpheli kütüphanelere odaklanmak, ilgili yığın izini ve durumu yeniden oluşturmak için yeterlidir.
Çekirdek dökümünü analiz ederken, program yürütmesini kontrol eden komutların (adım adım veya devam et gibi) artık bir anlam ifade etmediğini unutmayın, çünkü artık bağlı çalışan bir işlem yoktur. Bunun yerine, çökmenin nedenini veya programın nerede takılı kaldığını anlamak için yığın çerçevelerini, yerel ve küresel değişkenleri, bellek bölgelerini ve iş parçacıklarını inceleyen denetim komutlarına güvenirsiniz.
Modern RHEL'de gelişmiş bellek dökümü senaryoları ve GDB değişiklikleri
Bazı yüksek güvenlikli veya yüksek performanslı uygulamalar, belleklerinin bazı bölümlerini aşağıdaki gibi işaretler kullanarak dökümü yapılamaz olarak işaretler: VM_DONTDUMPBu da söz konusu belleğin çekirdek dosyalarına yazılmasını engeller. Bu, hassas verileri (örneğin, şifreleme anahtarları veya finansal kayıtlar) korur ve veri dökümü boyutlarını küçültür, ancak tam çevrimdışı analizi zorlaştırır.
Her şeyi, hatta normalde bellek dökümlerinden hariç tutulan alanları bile yakalama konusunda güçlü bir ihtiyacınız varsa, GDB'yi bellek dökümü yapmama bayrağını yok sayacak ve kapsamlı bir bellek dökümü yapmaya zorlayacak şekilde yapılandırabilirsiniz. GDB, geçersiz kılma seçenekleri sunar. VM_DONTDUMP ve adli inceleme veya detaylı hata ayıklama için tüm işlem belleğini bir çekirdek dosyasına aktarın.
Araçlar tarafında ise, RHEL 8 ile birlikte gelen GDB sürümü, özellikle terminal çıktısını ayrıştırmak için kullanılan alanlarda, RHEL 7'ye kıyasla bir dizi önemli ve davranışsal değişiklik getiriyor. Red Hat, metinsel çıktıları kazımak yerine, programatik kullanım için tasarlanmış olan GDB'nin Python API'sini veya Makine Arayüzü (MI) protokolünü kullanarak komut dosyaları yazmayı önermektedir.
Önemli değişiklikler arasında, argüman genişletmeye olanak sağlamak için GDBserver'ın alt süreçleri bir kabuk aracılığıyla başlatması, GCJ (Java) desteğinin kaldırılması, bakım sembol dökümü komutları için güncellenmiş sözdizimi ve uzaktan hata ayıklamayı daha iyi desteklemek için sysroot işleminde yapılan düzenlemeler yer almaktadır. HP-UX XDB uyumluluğu gibi bazı komutlar ve modlar remotebaud, kullanımdan kaldırıldı veya daha genel eşdeğerleriyle değiştirildi, örneğin set serial baud.
Ek olarak, GDB aşağıdaki gibi sınırlamalar getirdi. max-value-size Çok büyük değerler yazdırılırken sınırsız bellek tahsisini önlemek için, komut geçmişi boyutunun kontrol edilme şekli değiştirildi. GDBHISTSIZE yerine HISTSIZEve adayların tamamlama sayısına bir sınır ekledi. set max-completions. Bu güvenlik önlemleri, arızalı veya bozuk programlarda hata ayıklama sırasında donmaları veya aşırı bellek tüketimini önlemeye yardımcı olur.
Linux'ta C ve C++ geliştiricileri için net sonuç, güncellenmiş komutların ve yapılandırma ayarlarının farkında olmanız koşuluyla, büyük kod tabanlarına ve garip hata senaryolarına uyum sağlayabilen, daha sağlam ve betiklenebilir bir hata ayıklayıcıdır. GDB, GCC ve Clang/LLVM gibi modern derleyici altyapılarıyla (ve IBM Open XL C/C++ on Power gibi çözümlerle) birleştiğinde, Linux üzerinde karmaşık yerel yazılımların geliştirilmesi ve sorun gidermesi için güçlü bir araç zincirinin omurgasını oluşturur.
Doğru derleyiciyi ve IDE'yi seçmek, DWARF hata ayıklama bilgilerini etkinleştirmek ve hata ayıklama bilgisi paketlerini yüklemek, ayrıca GDB, strace, ltrace, SystemTap ve core-dump iş akışlarından yararlanmak, ilk izlenimleriniz yavaş bir VS Code hata ayıklama oturumundan kaynaklanmış olsa bile, size hızlı, şeffaf ve en büyük arka uçlar için uygun bir Linux C/C++ ortamı sağlar. Doğru yapılandırma ve mevcut araçların farkında olunmasıyla, Linux'ta hata ayıklama yalnızca Windows'taki Visual Studio'nun rahatlığına ulaşmakla kalmaz; birçok senaryoda, C ve C++ uygulamalarınızın gerçekte nasıl davrandığına dair daha ince bir kontrol ve daha derin bir görünürlük sağlar.
