2016-06-09 3 views
2

Unter Mac OS X und im iOS-Simulator (beide x86) können wir den Debugger (LLDB) mithilfe der Anweisung int3 in Inline-Assemblierung abfangen. Das ist gut, weil es zu einer bestimmten Codezeile führt, aber wir können sofort fortfahren, indem wir im Debugger auf continue klicken.Wie kann ich den Debugger abfangen und auf iOS-Hardware fortsetzen?

Gibt es eine Möglichkeit, dies auf iOS-Hardware zu tun?

An answer to an older question Erwähnungen raise(SIGINT) die soweit ich sehe (aus Prüfung signal.h) nicht existiert. Eine andere Antwort erwähnt die Assembleranweisung trap, die einen Build-Fehler verursacht ("Unknowned instruction mnemonic"). Ebenfalls unerkannt ist die BKPT Montageanleitung mentioned in ARM documentation.

Ich habe versucht, __builtin_trap() die fast, fast macht was ich will, aber erlaubt mir nicht weiterzumachen. Ich treffe es, es sei denn, ich fahre den Befehl Zeiger manuell mit jump +1 oder register write pc `$pc+8\`, die viel weniger bequem ist als nur weiter zu schlagen.

Ich baue für iOS 9 für 32- und 64-Bit-Geräte mit Xcode 7.3.1. Jede Hilfe wird geschätzt!

+1

Downvoter, will erklären? – Luke

+0

Ich denke, er hat Ihre Frage abgelehnt, da sowohl signal() als auch SIGINT Teil von Standard C sind. Http://opensource.apple.com//source/xnu/xnu-1456.1.26/bsd/sys/signal.h – diegog

+0

raise (SIGINT) kann funktionieren, aber nicht immer zuverlässig, irgendwann wird es ein wenig später aufhören, und Sie müssen den Thread-Baum laufen, um zu finden, wo der Breakpoint ist. Ich benutze diese Lösung einmal und dann entfernt.Ich fand später, dass ASSERT aufhören sollte, ohne weiterzugehen, Sie sollten sich ihnen stellen, anstatt sie zu ignorieren, warum wollen Sie dann behaupten? –

Antwort

1

Apples libc signal.h enthält XNU des sys/signal.h, die nicht SIGINT definieren (auf allen Plattformen):

// [...] 

#define SIGHUP 1 /* hangup */ 
#define SIGINT 2 /* interrupt */ 
#define SIGQUIT 3 /* quit */ 
// [...] 

Während also kann ich nicht bestätigen, dass diese Praxis in der Tat (von einem iOS 9 Gerät aufgrund mangel funktioniert meinerseits), sollte die Barriere, die dich zurückgehalten hat, eigentlich kein Problem sein.

Wie für die Montageanleitung ist BKPT ein gültiger ARM-Befehl, allerdings nur für A32. Die A64-Variante heißt BRK.
Wenn Sie fette Binaries erstellen und eines davon bedingungslos verwenden, treten immer Compilerfehler auf.

Beachten Sie auch, dass beide Anweisungen einen unmittelbaren Wert erfordern (der an den Debugger übergeben wird). Wenn Sie diesen Wert auslassen, wird auch ein Compilerfehler erzeugt.

Das heißt, sollten Sie in der Lage sein, Debug-Anweisungen für die A32 und A64 mit einem einfachen #if einzufügen:

#if __LP64__ 
asm volatile("BRK 0"); 
#else 
asm volatile("BKPT 0"); 
#endif 

Sie 0 durch einen beliebigen Wert Ihrer Wahl zwischen 0 und 255 ersetzen können.

Ein Hinweis auf die TRAP Anweisung: Während Apple Assembler diese Anweisung für A32 zu akzeptieren scheint, und übersetzt sie in 0xe7ffdefe, wird eine „nicht anerkannte Befehlsmnemonik“ auf A64, analog zu der BKPT Anweisung erteilen.
Ich konnte auch keinen Hinweis auf die Anweisung im ARM Information Center oder in der Dokumentation von Apple finden.

+0

Einige gute Infos hier, danke! Leider hat BRK/BKPT das gleiche Problem wie __builtin_trap(). Ich werde SIGINT erneut versuchen und sehen, was passiert. – Luke

+0

SIGINT und SIGTRAP tun tatsächlich, was ich will, obwohl der Stack eine Ebene tiefer ist als das, was ich bevorzuge. Vielen Dank! – Luke

+0

Happy Ich konnte helfen. [Eine andere Antwort] (https://stackoverflow.com/a/20713868) erwähnt 'SVC', das ist das Nicht-Debug-Gegenstück zu' BKPT'/'BRK' - Vorsicht, wenn' asm ("SVC 0") 'funktioniert anders als' BKPT'/'BRK'? – Siguza

Verwandte Themen