2015-09-10 23 views
9

Sto provando a eseguire il debug di un'applicazione Android nativa dal debugging nativo di Android Studio usando lldb.
La mia app nativa contiene una libmain.so compilata ed eseguita da Android Studio e un'altra libother.so esterna compilata da me. quando eseguo il debug, sono in grado di impostare i breakpoint in libmain.so ma non in libother.so.
Entrambi gli oggetti condivisi sono rimossi, ma in qualche modo Android Studio rende lldb noto della versione non cancellata di libmain.so. Voglio fare lo stesso per libother.so.LLDB: aggiungi un file di simboli?

Quale comando è necessario fornire a lldb in modo che carichi i simboli da un file non striptato sul mio computer locale?
Quando faccio image list vedo la .so principale con un percorso i punti alla sua versione unstripped locale:

/Users/username/Projects/gow/android/AppName/app/build/intermediates/binaries/debug/arm7/obj/armeabi-v7a/libmain.so

e la seconda .so con un percorso simile /var/folders/3w/5nr95lxx3qvdm2ylb8c8b7500000gn/T/./lldb/module_cache/remote-android/.cache/B5F32653-0000-0000-0000-000000000000/libother.so

Come faccio fai lldb a trovare la versione non lisce di libother.so?
Ho provato image add e ma non ha funzionato.

+0

fa a costruire l'applicazione con Gradle? Se è così, puoi condividere il tuo file di costruzione? Condivido anche il tuo file Android.mk –

+0

Lo faccio con gradle. Il file di build è identico a quello fornito con l'esempio di Teapot (https://developer.android.com/ndk/samples/sample_teapot.html) L'unica differenza è che nel mio progetto ho una cartella chiamata "jniLibs" così gradle trova questa cartella e aggiunge il .so in esso all'apk. Android.mk per la costruzione di .so è anche uno standard che è stato utilizzato per creare con l'ndk prima del supporto di Android Studio. usa clang e C++ _ static (troppo grande da aggiungere qui). Sto usando i latest NDK – shoosh

+0

Stai eseguendo il debug su Windows? I percorsi da te forniti presumono da Android. Ci sono ancora alcuni bug noti in NDK; quando il debugging con i breakpoint LLDB non funziona sempre su Windows; se ci si imbatte in questo, è possibile passare al debugging GDB come soluzione temporanea. –

risposta

2

utilizzare il "target.source-map" impostazione

lista (lldb) Impostazioni target.source-map
fonte-map - percorso di origine rimappature utilizzati per monitorare il cambiamento di posizione tra un source file una volta creato e dove esiste sul sistema corrente. Consiste in una serie di duplicati, il primo elemento di ogni duplicazione è una parte (a partire dalla radice) del percorso del file quando è stato creato e il secondo è il resto della gerarchia di build originale. radicato sul sistema locale. Ogni elemento dell'array viene controllato in ordine e il primo che risulta in una partita vince.

cioè

settings set target.source-map /build_src /source 

dove l'ambiente è in fase di costruzione e /build_src file the.dSYM (simboli) vengono copiati in /source

EDIT:

binari sono spesso spogliati dopo la costruzione e confezionato in una versione. Se i sistemi di compilazione salva un file eseguibile unstripped un percorso per questo eseguibile può essere fornito con il tasto DBGSymbolRichExecutable

È possibile scrivere un comando di shell che sarà dato un valore UUID ed è prevede di restituire un plist con alcuni tasti che specifica dove si trova il binario .

è possibile abilitare lo script di shell utilizzando:

% defaults write com.apple.DebugSymbols DBGShellCommands /path/to/shellscript 

Lo script di shell verrà richiamato con un valore stringa UUID come "23516BE4-29BE-350C-91C9-F36E7999F0F1".Lo script di shell può rispondere con un plist nel seguente formato:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";> 
<plist version="1.0"> 
<dict> 
     <key>23516BE4-29BE-350C-91C9-F36E7999F0F1</key> 
     <dict> 
       <key>DBGArchitecture</key> 
       <string>i386</string> 
       <key>DBGBuildSourcePath</key> 
       <string>/path/to/build/sources</string> 
       <key>DBGSourcePath</key> 
       <string>/path/to/actual/sources</string> 
       <key>DBGDSYMPath</key> 
       <string>/path/to/foo.dSYM/Contents/Resources/DWARF/foo</string> 
       <key>DBGSymbolRichExecutable</key> 
       <string>/path/to/unstripped/exectuable</string> 
     </dict> 
     <key>A40597AA-5529-3337-8C09-D8A014EB1578</key> 
     <dict> 
       <key>DBGArchitecture</key> 
       <string>x86_64</string> 
       ..... 
     </dict> 
</dict> 
</plist> 

per maggiori dettagli si veda:

http://lldb.llvm.org/symbols.html

https://www.mail-archive.com/[email protected]/msg01142.html

EDIT 2:

comando del Terminale per stampare l'UUID di un file eseguibile

$ xcrun dwarfdump --uuid <PATH_TO_APP_EXECUTABLE> 

source

+0

ma Non ho file .dSYM, solo l'oggetto condiviso non stoppato ... – shoosh

+0

vedere la modifica della mia risposta – Pat

+0

Questo è bello !, come faccio a impostare/ottenere l'UUID del mio .so apriori? – shoosh

1

Per completezza, quello che ho finito per fare è
- aggiunge -Wl,--build-id=sha1 alla LOCAL_LDFLAGS nel Android.mk di libmain.so
- aggiungere un link simbolico da /Users/username/Projects/gow/android/AppName/app/build/intermediates/binaries/debug/arm7/obj/armeabi-v7a/ all'oggetto condiviso unstripped .

Ciò consentiva all'LLDB di Android-Studio di trovare il file .so non stoppato, presentava correttamente i suoi simboli e mi consentiva di aggiungere punti di interruzione nel codice libmain.so.

2

Le risposte in questo thread sembrano essere specifiche per MacOSX. Sto usando Linux, quindi queste risposte non sono state di grande aiuto. Dopo un po 'di tempo ho capito, e qui è una soluzione molto semplice. Prima di fare "processo di allegare" è necessario eseguire il seguente comando:

settings set target.exec-search-paths /path/to/directory/with/unstripped/library/on/host 

Con questa impostazione lldb non ha problemi a trovare la versione corretta della libreria.

BTW, le ultime versioni di Android Studio non hanno alcun problema con le librerie esterne (infatti, la stessa tecnica viene utilizzata per impostare percorsi corretti tutte le librerie, sia "interne" che "esterne", almeno se si ' ri costruire con Gradle). Ma se usi lldb standalone, questo può essere molto utile.

Per evitare digitandolo dopo l'inizio di ogni sessione di debug è possibile salvare questo comando in un file (ad esempio lldb.cmd) e quindi avviare lldb come questo:

./lldb -S lldb.cmd 
+0

Sembra che questo non funzioni in AS 2.2.2 (anche in esecuzione sotto Linux). 'lldb' sta usando le librerie memorizzate in' .lldb/module_cache/... '(lo vedo in' elenco immagini') che non contiene simboli di debug. Ho inserito il percorso di ricerca exec sotto "Comandi di avvio LLDB" in "Esegui/Configurazione debug". Il percorso stesso punta a '{abs_path_to_project}/app/build/intermediates/ndkBuild/debug/obj/local/armeabi-v7a' in quanto questa directory contiene librerie condivise con simboli di debug. Qualche idea su cosa sto facendo male qui? –

+0

Non conosco i comandi di avvio di LLDB, non l'ho mai usato. Puoi semplicemente digitare manualmente, funziona? Le librerie appaiono nel tuo 'elenco immagini '? –

+1

Siamo spiacenti, le mie librerie non sono state compilate correttamente per il debug, la tua risposta ha funzionato per me dopo aver risolto il processo di compilazione. Grazie. –