Jestem pod OSX 10.8.4 i zainstalowałem gdb 7.5.1 z homebrew (motywacja zdobądź nowy gdb z nowymi funkcjami, takimi jak --with-python itp ...)
Krótko mówiąc, kiedy uruchamiam debugowanie w projekcie C ++ Eclipse, otrzymuję:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Unable to find Mach task port for process-id 46234: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
Unable to find Mach task port for process-id 46234: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
Postępowałem zgodnie z różnymi sugestiami dotyczącymi podpisywania kodu
- https://sourceware.org/gdb/wiki/BuildingOnDarwin
- częściowo http://www.noktec.be/archives/1251 z różnymi poprawkami
Więc zrobiłem:
- Skonfiguruj certyfikat
- Podpisz gdb -> codeign -s gdb-cert / usr / local / bin / gdb
Kiedy ponownie uruchamiam debugowanie w Eclipse, pojawia się ten sam błąd, co powyżej „(sprawdź, czy gdb jest oznaczony kodem - patrz taskgated (8))”.
Jeśli ustawię gdb z powrotem na starszą wersję gdb (w preferencjach gdb Eclipse) / usr / libexec / gdb / gdb-i386-apple-darwin, debugowanie przebiega zgodnie z oczekiwaniami.
Jakieś rozwiązania / wskazówki?
Dzięki
Pelle
Odpowiedzi:
Ten błąd występuje, ponieważ OSX implementuje politykę dostępu pid, która wymaga podpisu cyfrowego dla plików binarnych, aby uzyskać dostęp do innych identyfikatorów procesów. Aby umożliwić gdb dostęp do innych procesów, musimy najpierw podpisać kod binarny. Podpis ten zależy od konkretnego certyfikatu, który użytkownik musi utworzyć i zarejestrować w systemie.
Aby utworzyć certyfikat podpisujący kod, otwórz aplikację Dostęp do pęku kluczy. Wybierz menu Dostęp do pęku kluczy -> Asystent certyfikatu -> Utwórz certyfikat…
Wybierz nazwę certyfikatu (np. Gdb-cert), ustaw Typ tożsamości na Katalog główny z podpisem własnym, ustaw Typ certyfikatu na Podpisywanie kodu i wybierz opcję Pozwól mi zastąpić wartości domyślne. Kliknij kilkakrotnie przycisk Kontynuuj, aż dojdziesz do ekranu Określ lokalizację dla certyfikatu, a następnie ustaw Pęk kluczy na System.
Kliknij dwukrotnie certyfikat, otwórz sekcję Zaufanie i ustaw Podpisywanie kodu na Zawsze ufaj. Zamknij aplikację Dostęp do pęku kluczy.
Zrestartuj usługę wyznaczoną na zadania i podpisz plik binarny.
źródło http://andresabino.com/2015/04/14/codesign-gdb-on-mac-os-x-yosemite-10-10-2/
W systemie macOS 10.12 (Sierra) i nowszych musisz także
Użyj gdb w wersji 7.12.1 lub nowszej Dodatkowo uniemożliwiaj gdb używanie powłoki do uruchamiania programu, który ma być debugowany. Możesz użyć następującego polecenia do tego wewnątrz gdb:
Możesz również umieścić to ostatnie polecenie w pliku o nazwie .gdbinit w swoim katalogu domowym, w którym to przypadku zostanie ono zastosowane automatycznie za każdym razem, gdy uruchomisz gdb
ŹRÓDŁO: https://sourceware.org/gdb/wiki/BuildingOnDarwin
źródło
macOS Sierra
z certyfikatami z podpisem własnym.sudo killall taskgated
jest kluczem do rozwiązania mojego problemuZrobiłem gdb na OSX 10.9 bez kodowania w ten sposób (opisane tutaj ):
Zainstaluj gdb z macports. (może możesz to pominąć)
sudo nano /System/Library/LaunchDaemons/com.apple.taskgated.plist
zmień łańcuch opcji z
-s
na-sp
w linii 22, kol 27.Zrestartuj komputer.
Użyj gdb. Jeśli zainstalowałeś go z portami mac, musisz użyć
ggdb
polecenia. Lub utwórz alias w swoim pliku konfiguracyjnym:alias gdb='ggdb'
i użyj polecenia „gdb”.
źródło
gdb
jakosudo
. Wydaje się, że jest to niepotrzebne zagrożenie bezpieczeństwa.Zaktualizowałem do
gdb 8.3
i nie byłem w stanie sprawić, by wszystko działało. Pomogło mi to:Gdzie treść
gdb.xml
to:Znalazłem to rozwiązanie tutaj: https://timnash.co.uk/getting-gdb-to-semi-reliably-work-on-mojave-macos/
Uwaga: bez uprawnienia mogłem biegać
gdb
tylko zsudo
.źródło
error: The specified item could not be found in the keychain.
Doświadczyłem tego samego problemu z GDB. Biegnę pod
Mac OS X 10.8.5
aką Mountain Lion. Używam wersji GDB7.7.1
.Skompilowałem swój program testowy za pomocą następującego polecenia:
Jeśli wpisałem polecenie
gdb sample.out
, otrzymuję ten sam tajemniczy komunikat o błędzie:Ten komunikat o błędzie to jednak czerwony śledź.
Rozwiązaniem, które znalazłem, było po prostu wywołanie GDB przy użyciu konta superużytkownika:
Dla mnie to działa dobrze.
I od tego momentu mogłem uruchomić GDB example.out bez używania sudo.
Mam nadzieję, że to pomaga i działa dla innych. RSVP, jeśli nie.
źródło
Nic z tego nie działało dla mnie i musiałem iść na dłuższą metę. Oto pełna lista kroków, które wykonałem, aby to działało.
Niestety, certyfikat systemowy dał mi
Unknown Error = -2,147,414,007
bardzo pomocne rozwiązanie, więc musiałem obejść ten problem.KeyChain Assistant -> Create certificate ->
Pick
login
,gdb-cert
,Code Signing
Skopiuj / przenieś certyfikat do pęku kluczy systemu (wprowadź hasło)
gdb-cert
) kliknijGet info
->Trust Always
startup-with-shell
Wprowadź w konsoli:
set startup-with-shell off
Zapamiętaj konfigurację:
echo "set startup-with-shell off" >> ~/. gdbinit
Przejdź do
System Preferences
->Users & Groups
->Unlock it
->Login Options
->Network Account Server
->Join
->Unlock it
->Edit
(menu) ->Enable Root User
sudo killall taskgated
codesign -fs gdb-cert "$(which gdb)"
PS. W końcu używam,
lldb
ponieważ to po prostu działa ( samouczek )źródło
Dla każdego, kto używa Sierra 10.12.6 (i nowszych wersji) i Homebrew,
/usr/local/bin/gdb
jest to symboliczne łącze do/usr/local/Cellar/gdb/8.0/bin/gdb
(lub dowolnej wersji, np.8.0.1
.).Musisz kodować zarówno link, jak i cel:
Lub, jeśli masz
greadlink
(zainstalowane przezbrew install coreutils
):źródło
Zastanawiam się, czy globalna zmiana w odpowiedzi na najwyżej głosowaną tutaj odpowiedź ma jakieś niezamierzone konsekwencje.
Zamiast włączać starą konwencję Tiger, taskgated pozwala na uruchomienie podpisanego kodu. Więc może być lepiej, aby uzyskać podpisany certyfikat dla gdb, podobny do odpowiedzi tutaj .
Po tym mogłem
sudo
używać gdb. Jeśli potrzebujesz użyć gdb bez sudo, być może ten link pomoże , uwaga, jeszcze tego nie próbowałem, ponieważ używaniesudo
jest na razie dobrym rozwiązaniem.źródło
To może nie być powiązane. Możesz użyć lldb na macOS zamiast gdb. Nie potrzebujesz tego kłopotu, aby zainstalować gdb.
lldb ( http://lldb.llvm.org ) jest już domyślnie zainstalowany w High Sierra
źródło
Mogę polecić przestrzeganie tego sedna: https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d#file-codesign_gdb-md
Ze sztuczką do pokonania:
unknown error = -2,147,414,007
podczas tworzenia certyfikatu opisanego tutaj: https://apple.stackexchange.com/a/309123Uwagi:
Ścieżka do gdb zainstalowanego jako
homebrew
pakiet powinna wyglądać następująco:/usr/local/Cellar/gdb/9.2/bin/gdb
I
csrutil enable --without debug
spowoduje komunikat orequesting unsupported configuration
, jak tutaj: https://totalfinder.binaryage.com/system-integrity-protectionTest:
źródło
gdb 8.3;
Mój problem jest taki sam, jak ten powyżej, rozwiązany przez
źródło