GNU gdb Fedora (6.8-37.el5)
Kernal 2.6.18-164.el5
Ik probeer fouten op te sporen in mijn toepassing. Elke keer dat ik het binaire bestand doorgeef aan de gdb, staat er echter:
(no debugging symbols found)
Hier is de bestandsuitvoer van het binaire bestand, en zoals je kunt zien is het niet verwijderd:
vid: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
Ik compileer met de volgende CFLAGS:
CFLAGS = -Wall -Wextra -ggdb -O0 -Wunreachable-code
Kan iemand me vertellen of ik hier iets simpels mis?
Antwoord 1, autoriteit 100%
Sommige Linux-distributies gebruiken de foutopsporingssymbolen in gdb-stijl niet. (IIRC zij geven de voorkeur aan dwarf2.)
Over het algemeen zullen gccen gdbsynchroon lopen wat voor soort foutopsporingssymbolen ze gebruiken, en het forceren van een bepaalde stijl zal alleen maar problemen veroorzaken; tenzij je weet dat je iets anders nodig hebt, gebruik gewoon -g.
Antwoord 2, autoriteit 90%
De meest voorkomende oorzaak van “geen foutopsporingssymbolen gevonden” wanneer -gaanwezig is, is dat er enkele “verdwaalde” -Sof -Sargument ergens op de linkregel.
Van man ld:
-s
--strip-all
Omit all symbol information from the output file.
-S
--strip-debug
Omit debugger symbol information (but not all symbols) from the output file.
Antwoord 3, autoriteit 94%
De applicatie moet zowel gecompileerdals gelinktzijn met de optie -g. D.w.z. je moet -gin zowel CPPFLAGSals LDFLAGSplaatsen.
Antwoord 4, autoriteit 23%
Vervang -ggdb door -g en zorg ervoor dat u het binaire bestand niet verwijdert met het strip-commando.
Antwoord 5, autoriteit 23%
Je moet ook -ggdb proberen in plaats van -g als je compileert voor Android!
Antwoord 6, autoriteit 14%
Ik weet dat dit lang geleden is beantwoord, maar ik heb de laatste tijd uren besteed aan het proberen op te lossen van een soortgelijk probleem. De installatie is een lokale pc met Debian 8 met gebruik van Eclipse CDT Neon.2, een externe ARM7-kaart (Olimex) met Debian 7. De gereedschapsketen is Linaro 4.9 met gdbserver op de externe kaart en de Linaro GDB op de lokale pc. Mijn probleem was dat de foutopsporingssessie zou starten en het programma zou worden uitgevoerd, maar breekpunten werkten niet en wanneer handmatig werd gepauzeerd, zou “geen bron kunnen worden gevonden”. Mijn compileerlijnopties (Linaro gcc) omvatten -ggdb -O0 zoals velen hebben gesuggereerd, maar nog steeds hetzelfde probleem. Uiteindelijk heb ik gdb correct geprobeerd op het externe bord en het klaagde over geen symbolen. Het merkwaardige was dat ‘bestand’ meldde dat debug niet was verwijderd op het uitvoerbare bestand van het doel.
Uiteindelijk heb ik het probleem opgelost door -g toe te voegen aan de linkeropties. Ik zal niet beweren dat ik volledig begrijp waarom dit hielp, maar ik wilde dit doorgeven aan anderen voor het geval het helpt. In dit geval had Linux inderdaad -g nodig voor de linkeropties.
Antwoord 7, autoriteit 5%
Ik hoop dat het systeem waarop u hebt gecompileerd en het systeem waarop u debugt, dezelfde architectuur hebben. Ik kwam een probleem tegen waarbij foutopsporingssymbolen van 32-bits binair weigerden te laden op mijn 64-bits machine. Overschakelen naar een 32-bits systeem werkte voor mij.
Antwoord 8, autoriteit 5%
Voor degenen die hier kwamen met deze vraag en die Qt gebruiken: in de release-configuratie is er een stap waarbij het binaire bestand wordt verwijderd als onderdeel van het uitvoeren van de make install. U kunt de configuratieoptie CONFIG+=nostripdoorgeven om dit niet te doen:
In plaats van:
qmake <your options here, e.g. CONFIG=whatever>
je voegt CONFIG+=nostriptoe, dus:
qmake <your options here, e.g. CONFIG=whatever> CONFIG+=nostrip