2012-10-19 8 views
17

Mam projekt z biblioteką współdzieloną (ładowaną dynamicznie) i próbuję go debugować. Pojawia się następujący komunikat o błędzie:"Brak pliku źródłowego o nazwie" debugowanie błędów Eclipse CDT

No source file named /home/username/Code/path/to/project/MyFile.cpp. 

Po szukał innych wątków, mam zapewnione, że jestem kompilacji z -g, i że odpowiednie foldery na karcie ścieżki źródłowe konfiguracji debugowania. Dziwne jest to, że podaje poprawną ścieżkę absolutną: plik, do którego się odwołuje, istnieje, więc nie rozumiem, dlaczego nie myśli, że tam jest.

Ktoś wie, co z tym zrobić?

Odpowiedz

22

Po prostu natknąłem się na ten sam problem, chociaż moje punkty przerwania znajdowały się w samym pliku wykonywalnym, a nie we współużytkowanej bibliotece. Aby rozwiązać ten problem, musiałem otworzyć „konfiguracji Debug”, wybierz moje konfiguracji debugowania i dostosować następujące ustawienia:

  • Na dole znajduje się link „Wybierz inny ...”, aby wybrać Create Process wyrzutnia. Kliknij w link. Zaznacz "Użyj ustawień specyficznych dla konfiguracji". Wybierz opcję "Standardowy wywoływacz procesu" i naciśnij "Ok".
  • Przejdź do zakładki "Debugger", a na górze zakładki wybierz "Debugger: gdb/mi". Co może/nie może zrobić różnicę: na tej samej karcie znajduje się również pole wyboru "Użyj pełnej ścieżki do pliku, aby ustawić punkty przerwania" - grałem z tym, ale nie ma to wpływu na obserwowany przez nas problem (oczywiście nasze ścieżki źródłowe są już pełne ścieżki).

Dla pułapki w bibliotekach dzielonych, może być konieczne dodatkowe informacje (szczególnie o odroczone breakpoints) od Debugging with eclipse cdt and gdb i Why does eclipse cdt ignore breakpoints.

Uwaga: Odnosi się to do Eclipse Kepler (4.3) i gdb 7.4.

+2

Dobra odpowiedź, myślę, że jest poprawna. Możesz także chcieć spojrzeć na to pytanie/.answer też: http://stackoverflow.com/q/801423/1284631 – user1284631

+0

W moim przypadku, po wykonaniu wszystkich powyższych czynności na próżno, skończyło się, że instalowanie nowszej wersji gdb (7.4) naprawił to. – harish

0

Miałem ten sam problem, ale moje rozwiązanie było inne. Otwórz katalog "debug/src" + "release/src" i upewnij się, że nie istnieją pliki [filename] .d, które zawierają nazwy wszystkich plików źródłowych, które mogły zmienić ich nazwy lub które już nie istnieją. Miałem jeden, usunąłem go, a ponieważ nie było więcej błędów.

Zakładam więc, przynajmniej w moim przypadku, że błędy są tworzone przez obiekty, które wypadły poza zakres.

2

Miałem ten sam problem, ale w moim przypadku to była moja wina. Niektóre z moich projektów miały konfigurację Release, a debugger naturalnie nie mógł znaleźć informacji o pliku źródłowym.

+0

Miałem ten sam problem. Zapomniałem skonfigurować mój projekt CMake używając '-DCMAKE_BUILD_TYPE = Debug'. – Ignitor

1

Miałem ten sam problem. Nie mogłem ustawić punktu przerwania w pliku biblioteki współużytkowanej (.so), skompilowanym w innym miejscu niż mój program. Aby rozwiązać ten problem:

  1. Przejdź do konfiguracji Debug zakładce Źródło
  2. Dodaj katalog kompilacji (użyłem lokalizację głównego makefile, który kompiluje wszystkie procesy, a nie gdzie makefile dla tego procesu znajduje).
  3. również kliknąć „podkatalogi są również wykorzystywane do kompilacji” (mój podproces makefile jest skompilowany w podkatalogu głównej lokalizacji)

jeszcze nie zorientowali się, jak dokonać tej zmiany dla wszystkich konfiguracji debugowania i przyszłości przeszłość, więc nie muszę dodawać tego katalogu za każdym razem, ale postaram się zaktualizować później, jeśli to zrozumiem.

-1

dla istniejącego kodu projektu Makefile. krok 1 sprawdź kompilację wszystkich źródeł za pomocą -g -o0 krok 2 użyj gdbserver i arm-yourversion-gdb, które będą dostępne w narzędziach sdk i gdb.

0

Może się to zdarzyć, jeśli masz zarówno cygwin, jak i mingw (lub inny wariant). Jeśli gcc z cygwin jest używany do kompilacji źródła, będziesz miał ścieżkę cygwin w pliku wykonywalnym. Następnie, jeśli debugger pochodzi z mingw, gdb nie będzie w stanie zinterpretować ścieżki cygwin. Najprostszym sposobem rozwiązania tego problemu jest przejście do Run -> Debug Configurations -> Debugger i ustawienie pełnej ścieżki do cygwin gdb (C: \ cygwin64 \ bin \ gdb.exe). To rozwiązało problem dla mnie.

0

Podążyłem za komentarzem @Andreasa Festera do zakładki Debugger w ustawieniach konfiguracji debugowania, ale nie mogę znaleźć "Debugger: gdb/mi", ale na zakładce Źródło usunąłem wszystkie elementy i dodałem "Ścieżkę bezwzględnego pliku", klikając Przycisk "Dodaj ..." po prawej stronie okna. Pomogło mi w tym problemie.