LLDB: Symboldatei hinzufügen?

Question

Ich versuche, eine android native App von Android Studio natives Debuggen mit lldb zu debuggen.
Meine native App enthält eine libmain.so, die von Android Studio kompiliert und ausgeführt wird und eine andere externe libother.so von mir kompiliert. Beim Debuggen kann ich Haltepunkte in libmain.so, aber nicht in libother.so setzen.
Beide freigegebenen Objekte werden entfernt, aber irgendwie macht Android Studio lldb über die nicht entfernte Version von libmain.so bekannt. Ich möchte dasselbe für libother.so tun.

Welchen Befehl muss ich lldb geben, damit es die Symbole aus einer nicht entfernten Datei auf meinem lokalen Rechner lädt?
Wenn ich image list sehe ich das Haupt .so mit einem Pfad um die Punkte zu seiner lokalen unstripped Version:

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

und den zweiten .so mit einem Pfad wie /var/folders/3w/5nr95lxx3qvdm2ylb8c8b7500000gn/T/./lldb/module_cache/remote-android/.cache/B5F32653-0000-0000-0000-000000000000/libother.so

Wie kann mich make lldb finde die ungeschlitzte Version von libother.so?
Ich versuchte image add und target symbols add, aber es hat nicht funktioniert.

Answer 1

nutzen die "target.source-Karte" -Einstellung

(LLDB) Einstellungen Liste target.source-Karte
Quelle-Karte - Quellpfad Neuzuordnungen verwendet, um den Standortwechsel zwischen einem verfolgen Quelldatei wenn gebaut, und wo es auf dem aktuellen System existiert. Es besteht aus einem Array von Duples, das erste Element jedes Duple ist ein Teil (beginnend an der Wurzel) des Pfads zur Datei, wenn es wurde gebaut, und die zweite ist, wo der Rest der ursprünglichen Build-Hierarchie ist verwurzelt auf dem lokalen System. Jedes Element des Arrays wird der Reihe nach überprüft und das erste, das zu einer Übereinstimmung führt, gewinnt.

dh

settings set target.source-map /build_src /source 

, wo die Gebäudeumgebung ist unter /build_src und the.dSYM Dateien (Symbole) unter kopiert werden /source

EDIT:

Binaries werden nach oft gestrippt gebaut und in eine Version verpackt. Wenn Ihr Build-Systeme eine unstripped ausführbare spart auf diese ausführbare Datei ein Pfad kann mit der Taste DBGSymbolRichExecutable zur Verfügung gestellt werden

Sie einen Shell-Befehl schreiben, die einen UUID-Wert gegeben wird und ist erwartet eine plist mit bestimmten Tasten zurückzukehren das gibt an, wo die binäre ist.

Sie können das Shell-Script aktivieren mit:

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

Ihr Shell-Skript wird aufgerufen mit einem UUID-Zeichenfolge-Wert wie "23516BE4-29BE-350C-91C9-F36E7999F0F1".Der Shell-Skript kann mit einem plist in folgendem Format antworten:

<?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> 

für weitere Details siehe:

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

https://www.mail-archive.com/lldb-dev@cs.uiuc.edu/msg01142.html

EDIT 2:

Terminal-Befehl um die Build-UUID einer ausführbaren Datei zu drucken

$ xcrun dwarfdump --uuid <PATH_TO_APP_EXECUTABLE> 

source

Answer 2

Für Vollständigkeit, was ich am Ende tun ist
- fügen -Wl,--build-id=sha1 zum LOCAL_LDFLAGS im Android.mk von libmain.so
- fügen Sie einen Symlink von /Users/username/Projects/gow/android/AppName/app/build/intermediates/binaries/debug/arm7/obj/armeabi-v7a/ zum unstripped gemeinsam genutztes Objekt .

Das erlaubte LLDB von Android-Studio, das nicht entfernte .so zu finden, seine Symbole korrekt darzustellen und erlaubte mir, Haltepunkte im libmain.so-Code hinzuzufügen.

Answer 3

Die Antworten in diesem Thread scheinen spezifisch für MacOSX zu sein. Ich benutze Linux, daher waren diese Antworten nicht sehr hilfreich. Nach einiger Zeit habe ich es herausgefunden, und hier ist eine sehr einfache Lösung. Bevor Sie „Prozess anhängen“ sollten Sie den folgenden Befehl ausführen:

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

Mit dieser Einstellung LLDB hat keine Probleme die richtige Version der Bibliothek zu finden.

BTW, neueste Versionen von Android Studio haben keine Probleme mit externen Bibliotheken (in der Tat, die gleiche Technik wird verwendet, um korrekte Pfade alle Bibliotheken, sowohl "interne" und "externe", zumindest wenn Sie baue mit Gradle). Aber wenn Sie Standalone lldb verwenden, kann dies sehr praktisch sein.

Um zu vermeiden, es nach dem Start jeder Debug-Sitzung eingeben Sie diesen Befehl (z lldb.cmd) und starten Sie dann LLDB wie diese Datei speichern:

./lldb -S lldb.cmd