Debugowanie kodu Android NDK C/C++ w środowisku Eclipse - punkty przerwania nie są trafiane

Question

Pobrałem pakiet SDK systemu Android dla systemów Linux i Android NDK. Zainstalowano ADT, zainstalowałem CDT.

Stworzyłem projekt Androida i dodano obsługę natywną (jni). Następnie napisałem natywną funkcję w kodzie java, który eksportuje w kodzie C++. W kodzie C++ zdefiniowałem tę funkcję.

Java-code:

static { 
    System.loadLibrary("test"); 
} 

private native String get_text_from_cpp(); 

C++ kod (h):

extern "C"{ 
    JNIEXPORT jstring JNICALL Java_com_example_test_MainActivity_get_1text_1from_1cpp(JNIEnv *, jobject); 
} 

C++ kod (CPP):

JNIEXPORT jstring JNICALL Java_com_example_test_MainActivity_get_1text_1from_1cpp(JNIEnv * env, jobject){ 
    return env->NewStringUTF("hello from C++"); 
} 

Kod działa bez błędów. Ale kiedy ustawiam punkt przerwania w kodzie C++, to nie jest trafiony.

build-NKD NDK_DEBUG = 1 - są wliczone

ja po tej instrukcji http://tools.android.com/recent/usingthendkplugin

Android.mk w JNI/ma LOCAL_CFLAGS: = -g

Czytałem bardzo dużo informacji, ale nie można dostosować Eclipse. Proszę, pomóżcie każdemu.

PS: Przykro mi, że mój angielski nie jest moim ojczystym językiem. Mam trudności z pisaniem.

Dodaj: Również podczas debugowania w konsoli pokazuje: „ostrzeżenie. Nie można załadować symbole biblioteki współdzielone dla 95 bibliotek, np/system/bin/łącznik Użyj«info sharedlibrary»polecenie, aby zobaczyć pełną listę . Czy potrzebujesz "set solib-search-path" lub "set sysroot"? ostrzeżenie: Nie można znaleźć funkcji dynamicznego linku łącznika GDB będzie ponawiał próbę.W tym czasie prawdopodobnie jest , że GDB nie może debugować inicjalizatorów bibliotek wspólnych lub rozwiązuj oczekujące punkty przerwania po dlopen(). "

Answer 1

Twoja aplikacja bardzo wcześnie wykonuje funkcję JNI, więc debugger nie jest jeszcze gotowy. Niestety, to zajmuje trochę czasu dla gdb do ustanowienia połączenia zdalnego, zobacz http://visualgdb.com/documentation/appstartup

Zamiast walczyć z wiatrakami, dodać przycisk na swojej działalności, a nazywają tę samą metodę natywną onClick() tego przycisku - to będzie łatwiej złapać punkt przerwania.

BTW, ostrzeżenie o 95 bibliotekach jest całkowicie normalne. Są to biblioteki systemowe, których nie chcesz debugować i dla których nie masz źródeł.

Answer 2

Możesz użyć narzędzia DS-5 CE Android Debug dostarczonego przez ARM jako wtyczki do Twojego zaćmienia. Działa bardzo dobrze i zapewnia bardzo dobry i łatwy interfejs do debugowania. Z mojego osobistego doświadczenia wynika, że ​​jest dużo lepiej niż tradycyjny sposób debugowania aplikacji ndk.

Patrz poniższy link, który dostarczy Ci ze szczegółami, jak korzystać z DS-5 debuggera:

https://developer.arm.com/products/software-development-tools/ds-5-development-studio/resources/tutorials/android-native-app-debug-tutorial

Answer 3

Sztuką używam jest stworzenie połączenia usleep jako pierwszy mieszkaniec wiersz w moim kodzie debugowania.

To sprawia, że ​​wątek jest uśpiony i daje debuggerowi szansę na przygotowanie się do ciebie.

#include <unistd.h> 

. 
. 
. 

#ifndef NDEBUG 
usleep(5000 * 1000); 
#endif 

Answer 4

rozważyć dodanie:

android.os.Debug.waitForDebugger();

przed swoim ojczystym rozmowy, to sprawia, że ​​app czekać aż debugera przywiązuje może pomóc uniknąć spania/używając przycisku.

Answer 5

Po zmaga się dużo debugować na Eclipse to mój przepis:

Czy zwykłe czynności:

• Dodaj android.os.Debug.waitForDebugger(); przed załadowaniem natywną bibliotekę. To może pomóc.
• Dodaj APP_OPTIM := debug w Application.mk
• produkcji z ndk-build NDK_DEBUG=1

Następnie co znalazłem różne:

• Otwórz konsolę i uruchom:

adb pull /system/bin/linker <your_project_base_dir>/obj/local/armeabi/linker

W zależności od urządzenia może być konieczne wpisanie armeabi lub armeabi-v7a. Wystarczy tylko zrobić to raz (zauważyłem że działa ndk-gdb ręcznie robił to Wykonanie tego polecenia ręcznie punkty przerwania zaczął działać.)

• Wreszcie do debugowania skorzystać z menu „Uruchom -> Debug As -> Android Native Aplikacja”

Answer 6

miałem ten problem, a jedyną rzeczą, która pracowała dla mnie było oddanie

Thread.sleep(2000); 

przed bibliotekę JNI jest załadowany. Dało to wystarczająco dużo czasu na dołączenie debuggera przed wywołaniem aplikacji pod numerem System.loadLibrary. Pomógł mi zlokalizować problem kodu C++.