gdb: "Nie załadowano tablicy symboli"

90

Wciąż otrzymuję ten komunikat o błędzie podczas próby dodania punktu przerwania w gdb.

Użyłem tych poleceń do kompilacji:

gcc -g main.c utmpib2.c -o main.o
and:
cc -g main.c utmpib2.c -o main.o
and also:
g++ -g main.c utmpib2.c -o main.o

Próbowałem też „-ggdb” zamiast „-g” i nadal otrzymuję ten komunikat o błędzie.

Następnie wykonuję gdb:

$gdb

W gdb:

(gdb)exec-file main.o
(gdb)break 59
No symbol table is loaded. Use the "file" command.

c gdb

— user994165
źródło

Och, miałem na myśli maino. Zaktualizowałem to. Próbowałem też użyć „-ggdb” i nadal powoduje to ten sam problem.

— user994165

Pokaż nam dokładnie, jak wywołujesz gcc i gdb. Kopiuj i wklej, aby uniknąć błędów.

— Piotr Praszmo

1

Zaktualizowałem moje polecenia. To jest naprawdę dziwne. Po prostu zaczęło działać. Wiem, że wcześniej uzyskiwałem dostęp do gdb za pomocą „gdb a.out” i otrzymywałem komunikat o błędzie, że plik a.out nie istnieje lub coś takiego. Następnie przełączyłem się na „plik wykonywalny”. Teraz próbowałem z a.out i jest napisane "Ten GDB został skonfigurowany jako" i486-linux-gnu "" i można ustawić punkty przerwania.

— user994165

och, duh, określałem zły plik a.out. Postępowałem zgodnie z samouczkiem dotyczącym gdb, nie myśląc o zmianie nazwy pliku na własną.

— user994165

58

Przede wszystkim masz w pełni skompilowany program, a nie plik obiektowy, więc usuń .orozszerzenie. Teraz zwróć uwagę na to, co mówi komunikat o błędzie, który dokładnie informuje , jak rozwiązać problem: „Nie załadowano żadnej tablicy symboli. Użyj polecenia„ plik ” .”

(gdb) exec-file test
(gdb) b 2
No symbol table is loaded.  Use the "file" command.
(gdb) file test
Reading symbols from /home/user/test/test...done.
(gdb) b 2
Breakpoint 1 at 0x80483ea: file test.c, line 2.
(gdb)

Lub po prostu przekaż program w wierszu poleceń.

$ gdb test
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[...]
Reading symbols from /home/user/test/test...done.
(gdb) b 2
Breakpoint 1 at 0x80483ea: file test.c, line 2.
(gdb)

— Kevin
źródło

Przepraszam, jestem gdb noobem. To rozwiązanie (i żadne inne rozwiązanie w tym pytaniu) działa z gdb na WSL w systemie Windows, czy masz dla mnie jakąś sugestię?

— aderchox

141

Musisz dodać dodatkowy parametr -g, który generuje informacje debugowania na poziomie źródła. Będzie wyglądać następująco:

gcc -g prog.c

Następnie możesz używać gdb w zwykły sposób.

— kralex
źródło

27

W moim przypadku ta odpowiedź rozwiązała problem za mnie, podczas gdy zaakceptowana odpowiedź nie miała znaczenia.

— frankster

8

Mam ten sam problem i śledziłem ten post , rozwiązałem mój problem.

Wykonaj następujące 2 kroki:

Upewnij się, że poziom optymalizacji to -O0
Dodaj -ggdbflagę podczas kompilacji programu

Powodzenia!

— Charles Chow
źródło

0

Za każdym razem, gdy gccna maszynie kompilującej i gdb na maszynie testującej mają różne wersje , możesz napotkać niezgodność formatu debuginfo .

Aby to naprawić, spróbuj obniżyć format informacji o debugowaniu:

gcc -gdwarf-3 ...
gcc -gdwarf-2 ...
gcc -gstabs ...
gcc -gstabs+ ...
gcc -gcoff ...
gcc -gxcoff ...
gcc -gxcoff+ ...

Lub dopasuj gdbdo tego gcc, którego używasz.

— ulidtko
źródło

0

Spotkałem się z tym problemem dziś rano, ponieważ korzystałem z tego samego pliku wykonywalnego w RÓŻNYCH systemach operacyjnych: po skompilowaniu programu gcc -ggdb -Wall test.c -o testna komputerze Mac (10.15.2) uruchomiłem gdbplik wykonywalny w Ubuntu (16.04) w moim VirtualBox.

Poprawka: skompiluj ponownie za pomocą tego samego polecenia pod Ubuntu, wtedy powinieneś być dobry.

— Wenhe Qi
źródło