Équivalent Xcode de ' __asm int 3 / DebugBreak() / Halt ?
https://stackoverflow.com/questions/37299
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Quelle est l'instruction pour provoquer un hard-break dans Xcode ?Par exemple sous Visual Studio, je pourrais faire '_asm int 3' ou 'DebugBreak()'.Dans certaines implémentations de GCC, il s'agit de asm("break 0") ou asm("trap").
J'ai essayé différents combos sous Xcode sans aucune chance.(l'assembleur en ligne fonctionne bien donc ce n'est pas un problème de syntaxe).
Pour référence, il s’agit d’une macro d’assertion.Je ne veux pas utiliser les définitions dans assert.h à la fois pour des raisons de portabilité et parce qu'elles semblent faire un abort() dans la version fournie par XCode.
John - Super, bravo.Pour référence, la syntaxe int 3 est celle requise pour les Mac et iPhone Intel.
Chris - Merci pour votre commentaire mais il existe de nombreuses raisons d'éviter la fonction assert() standard pour les bases de code portées sur différentes plates-formes.Si vous avez pris la peine de lancer votre propre assert, c'est généralement parce que vous disposez de fonctionnalités supplémentaires (journalisation, déroulement de la pile, interaction utilisateur) que vous souhaitez conserver.
Votre suggestion d'essayer de remplacer le gestionnaire via une implémentation de '__assert' ou similaire ne sera pas portable.L'« assert » standard est généralement une macro et, même si elle peut être mappée à __assert sur Mac, ce n'est pas le cas sur d'autres plates-formes.
La solution
asm {trap} ; Halts a program running on PPC32 or PPC64.
__asm {int 3} ; Halts a program running on IA-32.
Autres conseils
Vous pouvez simplement insérer un appel à Debugger() - cela arrêtera votre application dans le débogueur (si elle est exécutée sous le débogueur), ou l'arrêtera avec une exception si ce n'est pas le cas.
Aussi, n'évite pas assert() pour des "raisons de portabilité" — la portabilité est la raison pour laquelle elle existe !Il fait partie du standard C et vous le trouverez partout où vous trouverez un compilateur C.Ce que vous voulez vraiment faire, c'est définir un nouveau gestionnaire d'assertions cela interrompt le débogueur au lieu d'appeler abort();pratiquement tous les compilateurs C offrent un mécanisme permettant de le faire.
Généralement, cela se fait simplement en implémentant une fonction ou une macro qui suit ce prototype :
void __assert(const char *expression, const char *file, int line);
Il est appelé lorsqu'une expression d'assertion échoue.Habituellement, non assert() lui-même, c'est ce qui réalise "le printf() suivi de abort()" c'est le comportement documenté par défaut.En personnalisant cette fonction ou macro, vous pouvez modifier son comportement.
__builtin_trap();
Puisque Debugger() est désormais déprécié, cela devrait fonctionner à la place.
Pour la postérité :J'ai du code pour générer des arrêts au bon cadre de pile dans le débogueur et (éventuellement) suspendre l'application afin que vous puissiez attacher le débogueur juste à temps.Fonctionne pour le simulateur et l'appareil (et éventuellement le bureau, si jamais vous en avez besoin).Article exhaustivement détaillé sur http://iphone.m20.nl/wp/2010/10/xcode-iphone-debugger-halt-assertions/
J'ai trouvé ce qui suit dans un Forum Apple:
Xcode ne vient pas avec des pauses symboliques intégrées - mais elles sont rapides à ajouter.Accédez à la fenêtre des points d'arrêt et ajoutez :
-[NSException augmenter]
kill(getpid(), SIGINT);
Fonctionne dans le simulateur et l'appareil.
Il existe également la fonction suivante qui est disponible comme alternative multiplateforme droite Halt() :
#include <stdlib.h>
void abort(void);
Nous l'utilisons dans notre moteur multiplateforme pour l'implémentation iPhone en cas d'assertions fatales.Multiplateforme sur Nintendo DS/Wii/XBOX 360/iOS etc...
