Perisian pengaturcaraan C dan C++ dan alat penyahpepijatan pada Linux

Laman Utama » Python » Perisian pengaturcaraan C dan C++ dan alat penyahpepijatan pada Linux

Jika anda datang daripada latar belakang Windows + Visual Studio dan tiba-tiba mendarat di pangkalan kod C atau C++ yang besar di Linux, perubahan itu boleh terasa kejam. Melangkah melalui ratusan ribu baris dengan GDB di belakang editor seperti VS Code, menunggu 30-60 saat untuk setiap langkah, boleh membuatkan anda tertanya-tanya sama ada anda melakukan sesuatu yang sangat salah atau jika pembangunan Linux hanya lambat mengikut reka bentuk. Berita baiknya ialah rantai alat dan penyahpepijat Linux moden sangat berkebolehan; anda hanya perlu tahu cara menyediakannya dan alat yang sesuai dengan projek C/C++ yang besar.

Panduan ini membimbing anda melalui landskap penyusun C/C++, IDE dan alat penyahpepijatan di Linux, (lihat Kuasai Linux dari awal), daripada GCC, Clang/LLVM dan IBM Open XL C/C++ kepada GDB, Eclipse, SystemTap, strace, ltrace dan aliran kerja pembuangan teras lanjutan. Sepanjang perjalanan, kami juga akan menyentuh tentang persediaan pembelajaran klasik (seperti Geany + GCC) dan menunjukkan petua konkrit untuk mempercepatkan penyahpepijatan dan menjadikan pembangunan Linux dengan C dan C++ lebih hampir kepada keselesaan yang mungkin anda gunakan pada Windows.

Penyusun untuk C dan C++ pada Linux: GCC, Clang/LLVM dan IBM Open XL

Di Linux, rantai alat rujukan untuk C dan C++ masih GCC (Koleksi Pengkompil GNU), dengan g++ sebagai bahagian hadapan C++nya. Kebanyakan pengedaran menghantar GCC secara lalai, dan hampir semua tutorial, membina sistem dan saluran paip CI menganggap kehadirannya. Anda biasanya menyusun dengan arahan seperti gcc untuk C dan g++ untuk C++, sebagai contoh g++ -g -O2 main.cpp -o app untuk membina binari yang boleh nyahpepijat, dioptimumkan.

Clang dan ekosistem LLVM telah berkembang menjadi alternatif yang berkuasa kepada GCC di Linux, menawarkan kompilasi pantas, diagnostik yang sangat baik dan set alatan yang kaya (analisis statik, pemformatan kod, sanitizer dan banyak lagi). Clang ialah bahagian hadapan C/C++ yang dibina di atas LLVM, infrastruktur pengkompil sumber terbuka modular yang menyokong berbilang seni bina dan bahasa serta diselenggara secara aktif oleh komuniti yang besar.

IBM Open XL C/C++ untuk Linux on Power ialah rantai alat komersial yang mengintegrasikan rapat Clang/LLVM dengan kepakaran pengoptimuman pengkompil IBM yang telah lama wujud. Disasarkan pada sistem IBM Power, ia memanfaatkan ciri bahasa C/C++ moden (termasuk C++17), pengoptimuman LLVM standard dan keserasian dengan GCC untuk menyampaikan binari berprestasi tinggi pada perkakasan Power. Ini bermakna anda mendapat manfaat daripada ekosistem LLVM serta pengoptimuman yang ditala platform yang dibangunkan oleh IBM.

Untuk persekitaran lama, IBM masih menyediakan penyusun XL C/C++ yang lebih lama untuk Linux, jadi organisasi yang mempunyai rantai binaan sedia ada atau kekangan pensijilan boleh terus menggunakannya sambil mengguna pakai Open XL C/C++ secara beransur-ansur untuk beban kerja yang lebih baharu.

Persediaan pembelajaran klasik: GCC dan IDE ringan

Jika anda baru bermula dengan C atau C++ di Linux, persediaan yang sangat biasa dan berkesan ialah GCC serta IDE ringan seperti Geany. Geany adalah platform silang (Linux dan Windows), pantas, dan menyepadukan ciri asas seperti pengurusan projek, arahan binaan dan penyahpepijatan mudah tanpa overhed IDE berat sepenuhnya.

Banyak kursus C/C++ bentuk panjang untuk Linux mengesyorkan gabungan ini dengan tepat: GCC sebagai pengkompil dan Geany sebagai persekitaran pembangunan. Melalui tutorial sedemikian, anda biasanya mempelajari bahasa dari bawah: apakah pengkompil GNU dan cara menggunakannya, cara menstruktur program, cara bekerja dengan syarat, fungsi, tatasusunan, rentetan, penunjuk, struktur, kesatuan, fail I/O dan akhirnya konsep berorientasikan objek seperti pewarisan, pembebanan operator dan polimorfisme dalam C++.

Walaupun pilihan IDE berbeza-beza, nasihat rangkaian alat asas cenderung konsisten: gunakan GCC (atau g++) merentas platform apabila boleh. Pada Linux, ini adalah tetapan lalai; pada Windows dan macOS, anda boleh memasang GCC melalui MinGW, MSYS2, WSL, Homebrew atau alatan yang serupa, mengekalkan aliran kerja yang seragam merentasi sistem dan memudahkan perkongsian skrip dan Makefiles.

Walaupun IDE mengabstrak langkah binaan, memahami bahawa ia hanya memanggil gcc or g++ di sebalik tabir adalah penting untuk menyahpepijat isu binaan atau masa jalan yang kompleks. Pilihan seperti -g untuk maklumat nyahpepijat, tahap pengoptimuman seperti -O0, -O2 or -O3, dan bendera untuk mengubah suai amaran atau pematuhan piawai (-Wall, -std=c++17, dsb.) semuanya sangat penting apabila mendiagnosis pepijat halus.

Penyahpepijatan dalam pangkalan kod C++ yang besar: daripada Kod VS kepada GDB asli

Pembangun yang berpindah dari Visual Studio pada Windows ke Linux selalunya bermula dengan Kod Visual Studio ditambah sambungan berasaskan GDB dan dengan cepat menyedari bahawa langkah dalam penyahpepijat boleh menjadi sangat perlahan pada bahagian belakang yang besar. Tidak jarang berlaku kelewatan 30-60 saat pada setiap langkah apabila menyahpepijat sistem pemprosesan atau penghantaran dokumen yang besar dengan ratusan ribu baris dan banyak komponen bahagian belakang.

Pengalaman lembap ini biasanya bukan pengehadan GDB itu sendiri, tetapi lapisan penyepaduan atau konfigurasi antara Kod VS dan penyahpepijat asas. Isu dalam sambungan penyahpepijatan, cara titik putus disegerakkan, cara maklumat simbol dimuatkan dan cara arahan MI (Antara Muka Mesin) diterjemahkan semuanya boleh menyumbang kepada kelembapan besar-besaran dalam aplikasi dunia sebenar yang kompleks.

Terdapat isu lama yang diketahui dilaporkan dalam sambungan VS Code C/C++ yang berkaitan dengan prestasi melangkah dengan GDB di Linux. Bagi sesetengah pasukan, ini bermakna Kod VS hebat sebagai editor tetapi tidak semestinya pilihan terpantas sebagai bahagian hadapan untuk menyahpepijat perkhidmatan C++ raksasa; alternatif seperti IDE Antigraviti Google dan IDE asli wujud. Apabila prestasi adalah kritikal, ramai jurutera kembali menggunakan GDB secara langsung atau beralih kepada IDE asli yang disepadukan dengan lebih mendalam dengan rantai alat tempatan.

Jadi, jika anda mendapati bahawa setiap langkah dalam sesi nyahpepijat Kod VS anda di Linux mengambil masa setengah minit, jangan anggap penyahpepijatan Linux sememangnya lambat. Sebelum berputus asa, adalah bernilai menguji GDB dalam terminal secara langsung pada tingkah laku binari dan membandingkan yang sama. Selalunya, melangkah masuk ke dalam GDB adalah lebih pantas secara mendadak, yang menunjukkan kesesakan konfigurasi atau sambungan daripada masalah OS atau pengkompil asas.

Di kedai C++ yang besar di Linux, alternatif popular untuk penyahpepijatan yang selesa termasuk Eclipse dengan CDT (C/C++ Development Tooling), CLion, Qt Creator, KDevelop dan IDE asli lain yang berintegrasi lebih rapat dengan GDB dan sistem setempat. Persekitaran ini boleh menyediakan navigasi sumber, tetingkap tontonan dan titik putus yang kaya semasa masih menggunakan GDB di bawah hud tanpa overhed lapisan penyahpepijatan agnostik bahasa.

Maklumat nyahpepijat pada Linux: ELF, DWARF, info debug dan sumber nyahpepijat

Di Linux, atur cara yang disusun dan perpustakaan kongsi biasanya disimpan dalam fail ELF (Format Boleh Laksana dan Boleh Paut) dan maklumat nyahpepijat yang berkaitan dikodkan dalam format DWARF. DWARF mengandungi metadata yang diperlukan oleh penyahpepijat untuk memetakan kod mesin kembali ke fail sumber, nombor baris, fungsi, jenis dan pembolehubah.

Anda boleh memeriksa bahagian DWARF dalam binari ELF dengan alatan seperti readelf -w file, yang membuang rekod nyahpepijat mentah. Walaupun anda biasanya tidak membaca DWARF secara manual, ini mengesahkan sama ada maklumat nyahpepijat hadir dan boleh menjadi tidak ternilai untuk mendiagnosis isu jenis "tiada simbol dimuatkan" dalam GDB atau alatan lain.

Format nyahpepijat lama yang dipanggil STABS masih wujud tetapi dianggap usang dan tidak digalakkan pada pengedaran Linux moden seperti Red Hat Enterprise Linux. GCC dan GDB menyediakan sokongan usaha terbaik untuk STABS, tetapi alatan utama dalam ekosistem (contohnya Valgrind atau elfutils) mungkin tidak berfungsi dengan betul, itulah sebabnya DWARF amat disyorkan.

Oleh kerana data nyahpepijat cenderung menjadi besar, kebanyakan pengedaran memisahkannya daripada binari utama kepada pakej debuginfo dan sumber nyahpepijat yang berasingan. Boleh laku yang anda pasang daripada repositori lalai biasanya dilucutkan simbol nyahpepijatnya untuk menjimatkan ruang cakera dan mengurangkan jejak memori, manakala pakej info debug yang sepadan mengandungi data DWARF dan, secara pilihan, sumber nyahpepijat termasuk sumber yang sepadan.

Pada RHEL dan sistem yang serupa, anda secara eksplisit meminta maklumat nyahpepijat pada masa penyusunan menggunakan -g apabila membina projek anda sendiri dengan GCC. Untuk sistem dan perpustakaan pihak ketiga yang dipasang daripada pakej, anda boleh mendapatkan yang berkaitan debuginfo dan debugsource pakej daripada repositori nyahpepijat khusus, sering dibayangkan secara langsung oleh GDB apabila ia menyedari kehilangan simbol semasa sesi nyahpepijat.

Memasang dan mencari debuginfo untuk binari sistem

Apabila anda menyahpepijat atur cara C atau C++ yang bergantung pada pustaka sistem, pemasangan debuginfo untuk pustaka tersebut boleh membuat perbezaan malam dan siang dalam kualiti jejak belakang dan pemeriksaan berubah-ubah. Tanpanya, anda hanya melihat alamat mentah atau nama fungsi yang rosak dalam perpustakaan kongsi; dengan itu, anda mendapat surih tindanan tepat baris dan nama pembolehubah simbolik.

Pada pengedaran seperti RHEL, GNU Debugger (GDB) boleh mengesan secara automatik apabila maklumat nyahpepijat tiada untuk objek yang dimuatkan dan mencadangkan arahan konkrit untuk memasang yang diperlukan debuginfo pakej melalui dnf. Anda hanya menjalankan yang disyorkan dnf debuginfo-install ... arahan, sahkan apabila digesa, dan sistem mengambil dan memasang pakej simbol yang diperlukan untuk sesi anda.

Jika petunjuk automatik tidak tersedia, anda boleh mengenal pasti debuginfo yang diperlukan secara manual dengan mencari fail binari atau pustaka dengan alat seperti locate dan kemudian menanyakan pangkalan data RPM. . locate arahan datang daripada mlocate pakej, yang anda mungkin perlu pasang dan mulakan, dan setelah anda mempunyai laluan, anda boleh bertanya pakej mana yang memilikinya dan kemudian memasang varian debuginfo yang sepadan.

Terdapat situasi di mana pakej yang memasang binari tertentu tidak dapat ditentukan, contohnya apabila fail disalin secara manual atau dibina di tempat tanpa pembungkusan. Dalam kes tersebut, anda mungkin perlu kembali ke fail simbol tersuai atau, jika boleh, bina semula binari itu sendiri dengan -g didayakan supaya GDB mempunyai data nyahpepijat penuh.

Ingat bahawa pemasangan debuginfo untuk setiap perpustakaan tunggal dalam sistem jarang diperlukan dan boleh membazir. Fokus pada modul yang paling berkaitan dengan isu anda: perduaan aplikasi anda dan pustaka khusus tempat ranap atau gelagat tidak betul berasal, dan bukannya menarik pakej nyahpepijat untuk keseluruhan OS.

Menggunakan GDB untuk penyahpepijatan interaktif pada Linux

GDB ialah alat pusat untuk menyahpepijat aplikasi C dan C++ asli di Linux, mendedahkan kedua-dua antara muka baris arahan dan, melalui penyepaduan, bahagian hadapan grafik seperti Eclipse CDT. Pada Red Hat Enterprise Linux, pengedaran standard termasuk GDB berciri penuh bersama GUI pilihan.

Untuk menyahpepijat atur cara dari mula, anda biasanya menggunakan gdb ./program, konfigurasikan titik putus seperti yang diperlukan, kemudian lancarkan pelaksanaan di dalam GDB dengan run perintah. Sebagai alternatif, anda boleh melampirkan pada program yang sudah berjalan dengannya gdb -p <pid> atau dengan memulakan GDB dan menggunakan attach arahan bersama-sama dengan ID proses.

Jika GDB tidak dapat menyimpulkan sasaran boleh laku untuk PID tertentu semasa lampiran, anda boleh memberitahunya secara eksplisit binari mana yang hendak digunakan melalui file arahan dan kemudian teruskan untuk debug. Ini amat berguna apabila anda berurusan dengan pelancar tersuai, skrip pembalut atau persediaan berbilang binari di mana laluan boleh laku sebenar tidak jelas.

Setelah dilampirkan atau dilancarkan, anda mengawal aliran program dengan arahan seperti n (seterusnya), s (langkah), until, finish dan secara sederhana c (teruskan), sambil menghentikan penyahpepijat dengan q apabila selesai. Setiap arahan ini mempunyai semantik khusus tentang sama ada ia melangkah ke badan fungsi, berjalan sehingga baris tertentu atau menyambung semula pelaksanaan sehingga titik putus atau penamatan seterusnya.

Untuk memahami keadaan, GDB menyediakan perintah introspeksi yang kaya untuk memeriksa pembolehubah, susunan panggilan, daftar dan banyak lagi, dan juga menawarkan bantuan kontekstual melalui help info dan perintah yang serupa. Anda boleh menunjukkan baris sumber semasa dengan list, cetak pembolehubah dengan print, teroka bingkai tindanan dengan backtrace dan navigasi bingkai dengan frame, up dan down.

Titik putus, titik pantau dan keadaan dalam GDB

Dalam penyahpepijatan dunia sebenar, anda hampir tidak pernah melangkah secara membabi buta main(); sebaliknya, anda secara strategik meletakkan titik putus untuk menghentikan program dengan tepat di mana tingkah laku menjadi menarik. Perintah standard break membolehkan anda menetapkan titik putus sama ada mengikut fail dan nombor baris atau mengikut nama fungsi, dan GDB akan menjeda pelaksanaan pada pukulan seterusnya.

Sebagai contoh, anda boleh menetapkan titik putus pada baris sumber tertentu menggunakan sintaks seperti break file.cpp:123, atau putus pada permulaan fungsi dengan break my_function. Apabila lokasi titik putus dicapai, GDB menghentikan program, membenarkan anda memeriksa pembolehubah setempat, menyemak timbunan panggilan dan memutuskan sama ada untuk melangkah masuk, melangkah atau meneruskan.

Titik putus bersyarat adalah tidak ternilai apabila pepijat hanya muncul selepas banyak lelaran atau di bawah nilai input tertentu. Anda boleh mengaitkan keadaan Boolean yang ditulis dalam C atau C++ dengan titik putus supaya GDB hanya berhenti apabila keadaan itu dinilai kepada benar, secara mendadak mengurangkan hentian yang tidak perlu dan menjadikan gelung penyahpepijatan atau mesin keadaan kompleks lebih cekap.

Untuk memantau perubahan dalam data dan bukannya aliran kod, GDB menawarkan titik pantau, yang mencetuskan apabila ungkapan (selalunya pembolehubah) dibaca daripada atau ditulis kepada. Dengan arahan seperti watch, rwatch (baca) atau awatch (baca/tulis), anda boleh menghentikan pelaksanaan tepat apabila medan tertentu diubah suai atau diakses, yang amat membantu dalam menjejaki perubahan keadaan yang tidak dijangka.

Anda menguruskan semua titik putus dan titik pantau melalui arahan seperti info breakpoints or info br, dan anda boleh memadam mengikut nombor atau mengikut lokasi menggunakan delete dengan hujah yang sesuai. Ini memudahkan untuk menyimpan set titik putus aktif yang bersih dan mengelakkan kekeliruan apabila menyahpepijat merentas berbilang modul atau sesi.

Menyahpepijat proses berbilang benang dan bercabang

Menyahpepijat program C dan C++ yang menggunakan benang atau garpu secara meluas memerlukan kesedaran tambahan tentang cara GDB menjejaki konteks pelaksanaan. Secara lalai, GDB menetapkan urutan semasa dan kebanyakan perintah beroperasi pada urutan itu melainkan anda secara eksplisit menukar menggunakan thread dan pengecam benang.

Apabila program anda bercabang, tetapan set detach-on-fork menentukan sama ada GDB mengikuti kanak-kanak atau ibu bapa dan cara ia mengendalikan proses yang tidak diikuti. Anda boleh mengkonfigurasi GDB sama ada untuk mengekalkan kawalan kedua-duanya atau untuk melepaskan diri dari satu pihak secara automatik, bergantung pada sama ada ibu bapa, anak atau kedua-duanya adalah berkaitan untuk analisis anda.

Versi GDB yang lebih baharu telah mengembangkan cara thread dinomborkan, memperkenalkan ID thread per-inferior bersama-sama dengan ID thread global yang berbeza untuk keserasian. Pembolehubah kemudahan $_thread dan API Python InferiorThread.num kini mencerminkan penomboran per-inferior, manakala pengecam global tersedia melalui $_gthread dan InferiorThread.global_num, memastikan alatan lama berdasarkan ID global terus berfungsi.

Pengendalian isyarat dalam penyahpepijatan berbilang benang juga telah dipertingkatkan supaya isyarat sentiasa dihantar ke utas yang betul. Jika anda menukar urutan selepas isyarat menghentikan program dan kemudian cuba meneruskan, GDB boleh meminta pengesahan, menghalang salah hantar secara tidak sengaja dan menjadikan penyahpepijatan berkaitan isyarat lebih dipercayai.

Semua ini bermakna apabila menganalisis kebuntuan, perlumbaan atau ranap yang dicetuskan isyarat aneh, anda boleh bergantung pada model benang GDB untuk menjejaki laluan pelaksanaan yang betul dengan kawalan yang tepat. Digabungkan dengan titik putus, titik pantau dan titik tangkapan, ini membolehkan penyahpepijatan berbilang benang yang mantap walaupun dalam perkhidmatan C++ yang sangat serentak.

Mengesan panggilan sistem dan perpustakaan: strace, ltrace dan SystemTap

Kadangkala cara terpantas untuk memahami sebab program C atau C++ tidak berfungsi adalah dengan tidak melalui setiap baris, tetapi untuk memerhatikan cara ia berinteraksi dengan sistem pengendalian dan perpustakaan kongsinya. Linux menawarkan beberapa alat berkuasa untuk ini: strace, ltrace, SystemTap dan juga GDB sendiri melalui titik tangkapan khusus.

. strace panggilan sistem jejak utiliti—interaksi dengan kernel seperti open, read, write, mmap, execve dan seterusnya—bersama-sama dengan parameter dan nilai pulangannya. Anda boleh menjalankan program anda melalui strace atau lampirkan pada proses yang sedang berjalan oleh PID, secara pilihan menapis syscall mana yang hendak dipaparkan menggunakan ungkapan seperti -e trace=call dan mengawal sama ada untuk mengikuti anak bercabang atau berulir dengan -f.

Kerana aplikasi sebenar mengeluarkan sejumlah besar panggilan sistem, digabungkan strace dengan alat shell seperti tee adalah perkara biasa untuk melihat output secara langsung dan menyimpannya untuk analisis. Ini membantu anda mengenal pasti fail yang hilang, masalah kebenaran, tingkah laku rangkaian yang tidak dijangka atau isu peringkat OS lain yang mungkin tidak jelas dari dalam kod itu sendiri.

Melengkapkan strace, ltrace menumpukan pada panggilan ke fungsi perpustakaan kongsi dalam ruang pengguna, menunjukkan seruan dan nilai pulangan untuk fungsi yang dieksport daripada objek dinamik. Pada RHEL 8 terdapat had yang diketahui di mana ltrace tidak dapat mengesan sistem boleh laku tertentu, tetapi ia berfungsi seperti biasa untuk binari binari pengguna, menjadikannya alat yang berharga untuk memahami cara program anda menggunakan API perpustakaan.

SystemTap ialah rangka kerja pengesanan yang lebih maju yang membenarkan pengendali acara tersuai untuk acara kernel dan ruang pengguna menggunakan bahasa skripnya sendiri. Ia boleh menjadi lebih kompleks untuk digunakan daripada strace atau ltrace tetapi berskala lebih baik dan menyokong penapisan dan pengagregatan yang canggih. Untuk kemudahan, skrip sampel dipanggil strace.stp dihantar dengan SystemTap untuk meniru tingkah laku seperti strace menggunakan infrastruktur SystemTap.

GDB sendiri boleh mengambil bahagian dalam pengesanan dengan menggunakan titik tangkapan untuk syscalls dan isyarat, melalui arahan seperti catch syscall dan catch signal. Ini menyebabkan penyahpepijat menghentikan pelaksanaan apabila program melakukan panggilan sistem tertentu atau menerima isyarat tertentu, yang boleh menjadi sangat berguna apabila anda memerlukan kawalan terperinci semasa penyahpepijatan interaktif.

Lambakan teras dan penyahpepijatan bedah siasat dengan GDB

Apabila aplikasi C atau C++ ranap atau hang dalam cara yang sukar untuk dihasilkan semula secara interaktif, longgokan teras memberikan gambaran memori dan keadaannya pada saat genting. Longgokan teras ialah fail ELF yang mengandungi kandungan bahagian memori proses (tindanan, timbunan, pemetaan) semasa penamatan, yang boleh anda analisis kemudian dengan GDB seolah-olah anda dilampirkan pada masa ranap.

Untuk menggunakan pembuangan teras dengan berkesan, anda mesti memastikan ia benar-benar dijana dan tidak disekat oleh had sumber atau konfigurasi. Had shell seperti ulimit -c boleh menghalang fail teras daripada dicipta; menetapkan had kepada unlimited mengalih keluar penutup saiz, walaupun anda harus menyemak implikasi ruang cakera dalam sistem pengeluaran.

Pada sistem RHEL moden, systemd-coredump menguruskan pembuangan teras secara telus dan menyimpannya di lokasi seperti jurnal berpusat dan bukannya meninggalkannya core fail bertaburan di seluruh direktori. . coredumpctl alat membolehkan anda menyenaraikan ranap yang direkodkan, memeriksa metadata mereka dan mengeksport fail teras sebenar ke laluan yang dipilih untuk analisis yang lebih mendalam.

Apabila mencipta aliran kerja tangkap ranap sistemik, adalah perkara biasa untuk memasang sos pakej dan penggunaan sosreport untuk menjana bola tar dengan konfigurasi sistem dan log. Digabungkan dengan fail teras yang dieksport dan binari aplikasi, ini memberikan anda segala yang diperlukan untuk menganalisis ranap pada mesin yang berasingan atau menyerahkannya kepada pasukan atau vendor lain.

Anda juga boleh dengan sengaja mencetuskan pembuangan teras untuk proses yang tidak bertindak balas dengan menghantarnya isyarat batalkan atau menggunakan alatan seperti gcore, yang membuang memori proses semasa ia masih berjalan. semasa gcore dump, proses berhenti seketika, kemudian menyambung semula pelaksanaan biasa, membolehkan analisis luar talian keadaan bermasalah tanpa menamatkan perkhidmatan sepenuhnya.

Mencari simbol boleh laku dan simbol yang betul untuk analisis teras

Untuk menganalisis longgokan teras secara bermakna, GDB memerlukan kedua-dua fail teras dan boleh laksana yang tepat (serta mana-mana perpustakaan kongsi yang berkaitan) yang menghasilkannya. Ini penting kerana perduaan yang tidak padan—dibina daripada versi berbeza—boleh membawa kepada kesan belakang yang mengelirukan dan reka letak pembolehubah yang salah.

Alatan seperti coredumpctl info tunjukkan metadata terperinci untuk setiap teras yang ditangkap, termasuk laluan ke boleh laku utama dan ID binaan yang mengenal pasti binari secara unik. ID binaan mungkin kelihatan seperti cincangan heksadesimal yang panjang, dan anda boleh membandingkannya dengan ID binaan salinan tempatan anda bagi binari untuk memastikan ia adalah sama sebelum memulakan GDB.

Jika boleh laku dan perpustakaannya datang daripada pakej RPM, anda boleh gunakan sosreport dan pangkalan data pakej untuk mengambil versi tepat yang diperlukan. Dalam sesetengah kes, anda juga boleh memasang semula pakej yang sepadan pada mesin debug khusus dan kemudian menggunakan GDB set sysroot konfigurasi untuk menghalakannya pada susun atur perpustakaan bercermin untuk penyahpepijatan gaya jauh.

Sebaik sahaja anda mempunyai objek yang betul, anda memulakan sesi GDB dengan arahan seperti gdb /path/to/exe /path/to/core dan biarkan GDB memuatkan teras. Jika debuginfo tiada untuk mana-mana modul, GDB akan memaparkan mesej yang membayangkan pakej atau fail simbol yang perlu anda pasang untuk mendapatkan keterlihatan simbol penuh.

Jika simbol nyahpepijat aplikasi anda disediakan dalam fail berasingan dan bukannya melalui pakej, anda boleh memuatkannya secara eksplisit menggunakan symbol-file arahan di dalam GDB. Anda tidak diwajibkan untuk mempunyai maklumat nyahpepijat untuk setiap perpustakaan kongsi tunggal dalam teras; memfokuskan pada aplikasi anda sendiri dan perpustakaan yang disyaki biasanya cukup untuk membina semula timbunan dan keadaan yang berkaitan.

Apabila menganalisis lambakan teras, ingat bahawa arahan untuk mengawal pelaksanaan program (seperti langkah atau teruskan) tidak lagi masuk akal, kerana tiada proses langsung dilampirkan. Sebaliknya, anda bergantung pada arahan pemeriksaan—meneliti bingkai tindanan, pembolehubah tempatan dan global, kawasan memori dan benang—untuk membuat kesimpulan mengapa ranap sistem berlaku atau tempat program tersekat.

Senario pembuangan memori lanjutan dan perubahan GDB pada RHEL moden

Aplikasi keselamatan tinggi atau berprestasi tinggi tertentu menandakan bahagian memori mereka sebagai tidak boleh dibuang menggunakan bendera seperti VM_DONTDUMP, yang menghalang memori itu daripada ditulis ke dalam fail teras. Ini melindungi data sensitif (contohnya, kunci kriptografi atau rekod kewangan) dan mengurangkan saiz tempat pembuangan, tetapi menjadikan analisis luar talian penuh lebih sukar.

Jika anda mempunyai keperluan yang kuat untuk menangkap segala-galanya—termasuk kawasan yang biasanya dikecualikan daripada tempat pembuangan—anda boleh mengkonfigurasi GDB untuk mengabaikan bendera bukan pembuangan dan memaksa pembuangan memori yang komprehensif. GDB menyediakan pilihan untuk mengatasi VM_DONTDUMP dan buang keseluruhan memori proses ke dalam fail teras untuk forensik atau penyahpepijatan mendalam.

Dari segi perkakas, versi GDB yang dihantar dengan RHEL 8 memperkenalkan beberapa perubahan pecah dan tingkah laku berbanding RHEL 7, terutamanya di kawasan yang digunakan oleh orang ramai untuk menghuraikan output terminalnya. Daripada mengikis output teks, Red Hat mengesyorkan menulis skrip menggunakan API Python GDB atau protokol Antara Muka Mesin (MI), yang kedua-duanya direka untuk penggunaan program.

Perubahan ketara termasuk GDBserver melancarkan inferior melalui shell untuk membenarkan pengembangan hujah, penyingkiran sokongan GCJ (Java), sintaks yang dikemas kini untuk arahan pelupusan simbol penyelenggaraan dan pelarasan dalam pengendalian sysroot untuk menyokong penyahpepijatan jauh dengan lebih baik. Beberapa arahan dan mod, seperti keserasian HP-UX XDB dan remotebaud, telah bersara atau digantikan dengan yang setara generik seperti set serial baud.

Di samping itu, GDB memperkenalkan had seperti max-value-size untuk mengelakkan peruntukan memori yang tidak terhad apabila mencetak nilai yang sangat besar, mengubah cara saiz sejarah arahan dikawal melalui GDBHISTSIZE bukan HISTSIZE, dan menambah had pada calon pelengkap melalui set max-completions. Perlindungan ini membantu mengelakkan pembekuan atau penggunaan memori yang berlebihan apabila menyahpepijat program patologi atau rosak.

Kesan bersih untuk pembangun C dan C++ pada Linux ialah penyahpepijat boleh skrip yang lebih mantap yang berskala kepada pangkalan kod yang besar dan senario kegagalan yang pelik, dengan syarat anda mengetahui arahan dan tombol konfigurasi yang dikemas kini. Digabungkan dengan infrastruktur pengkompil moden seperti GCC dan Clang/LLVM (dan tawaran seperti IBM Open XL C/C++ on Power), GDB membentuk tulang belakang rantai alat yang berkuasa untuk membangunkan dan menyelesaikan masalah perisian asli yang kompleks di Linux.

Memilih pengkompil dan IDE yang betul, mendayakan maklumat nyahpepijat DWARF dan memasang pakej info debug, dan memanfaatkan aliran kerja GDB, strace, ltrace, SystemTap dan core-dump memberi anda persekitaran Linux C/C++ yang pantas, telus dan sesuai untuk bahagian belakang terbesar, walaupun jika tera pertama anda datang daripada sesi penyahpepijatan Kod VS yang lembap. Dengan konfigurasi dan kesedaran yang betul tentang alatan yang tersedia, penyahpepijatan pada Linux bukan sahaja sepadan dengan keselesaan Visual Studio pada Windows; dalam banyak senario, ia sebenarnya memberi anda kawalan yang lebih baik dan keterlihatan yang lebih mendalam tentang cara aplikasi C dan C++ anda benar-benar berkelakuan.