GNU/Linux >> Znalost Linux >  >> Linux

Ladění základních souborů generovaných v krabici zákazníka

Co se stane, když se základní soubor vygeneruje z jiné distribuce Linuxu, než je ta, kterou používáme ve vývojovém prostředí? Má trasování zásobníku vůbec smysl?

Pokud je spustitelný soubor dynamicky propojen, jako je ten váš, zásobník, který GDB vytvoří, (s největší pravděpodobností) není být smysluplný.

Důvod:GDB ví, že váš spustitelný soubor selhal voláním něčeho v libc.so.6 na adrese 0x00454ff1 , ale neví, jaký kód byl na této adrese. Takže to vypadá na vaše kopie libc.so.6 a zjistí, že toto je v select , takže to vytiskne.

Ale šance, že 0x00454ff1 je také ve výběru u vašich zákazníků kopii libc.so.6 jsou docela malé. S největší pravděpodobností měl zákazník na této adrese nějaký jiný postup, možná abort .

Můžete použít disas select a všimněte si, že 0x00454ff1 je buď uprostřed instrukce, nebo že předchozí instrukce není CALL . Pokud platí některá z těchto možností, vaše trasování zásobníku nemá smysl.

můžete pomozte si však sami:stačí získat kopii všech knihoven, které jsou uvedeny v (gdb) info shared ze zákaznického systému. Požádejte zákazníka, aby je namazal např.

cd /
tar cvzf to-you.tar.gz lib/libc.so.6 lib/ld-linux.so.2 ...

Poté ve vašem systému:

mkdir /tmp/from-customer
tar xzf to-you.tar.gz -C /tmp/from-customer
gdb /path/to/binary
(gdb) set solib-absolute-prefix /tmp/from-customer
(gdb) core core  # Note: very important to set solib-... before loading core
(gdb) where      # Get meaningful stack trace!

Poté zákazníkovi doporučujeme, aby spustil binární soubor -g, aby bylo snazší ladit.

hodně lepší přístup je:

  • sestavit pomocí -g -O2 -o myexe.dbg
  • strip -g myexe.dbg -o myexe
  • distribuovat myexe zákazníkům
  • když zákazník dostane core , použijte myexe.dbg k odladění

Budete mít úplné symbolické informace (soubor/řádek, místní proměnné), aniž byste museli zákazníkovi posílat speciální binární soubory a aniž byste prozradili příliš mnoho podrobností o svých zdrojích.


Můžete skutečně získat užitečné informace z výpisu z havárie, dokonce i z optimalizovaného kompilace (ačkoli se tomu technicky říká "velká bolest v prdeli.") a -g kompilace je skutečně lepší a ano, můžete to udělat, i když je počítač, na kterém došlo k výpisu, jiná distribuce. V podstatě s jednou výhradou jsou všechny důležité informace obsaženy ve spustitelném souboru a končí ve výpisu.

Když porovnáte základní soubor se spustitelným souborem, ladicí program vám bude schopen říct, kde došlo k havárii, a ukáže vám zásobník. To samo o sobě by mělo hodně pomoci. Měli byste si také zjistit co nejvíce o situaci, ve které se to děje - dokážou to spolehlivě reprodukovat? Pokud ano, můžete jej reprodukovat?

Zde je upozornění:místo, kde se pojem „všechno je tam“, hroutí, jsou soubory sdílených objektů, .so soubory. Pokud selže kvůli problému s nimi, nebudete mít tabulky symbolů, které potřebujete; můžete vidět pouze knihovnu .so děje se to v.

Existuje řada knih o ladění, ale nenapadá mě žádná, kterou bych doporučil.


Linux
  1. Vložit soubory bez oddělovače?

  2. „Výchozí“ možnosti instalace Centos 6?

  3. Jak mohu analyzovat soubor výpisu jádra programu pomocí GDB, když má parametry příkazového řádku?

  1. Grep:Vyčerpaná paměť?

  2. Přejmenovat soubory v adresáři?

  3. Několik příkazů GDB – ladění jádra, rozebrání, načtení sdílené knihovny

  1. .o soubory vs. .a soubory

  2. wc gzip soubory?

  3. ladění šablon pomocí GDB