Débogage des applications C++ Builder Windows 64 bits
Remonter à Développement d'applications C++ Builder Windows 64 bits
Sommaire
Débogueur C++ basé sur LLDB pour WIN64
RAD Studio 10.4 introduit un nouveau débogueur C++ pour Win64, basé sur LLDB. Le compilateur utilise le format DWARF version 4 pour les informations de débogage.
Le nouveau débogueur LLDB de RAD Studio offre une plus grande stabilité lors du débogage. La nouvelle technologie de débogage couplée aux informations de débogage générées renforcent les capacités d'évaluation, d'inspection et de débogage. De plus, le débogueur prend en charge des types complexes comme les collections STL ou les chaînes via les formateurs.
Formateurs
L'inspection ou l'évaluation des types complexes peut poser problème lors du débogage d'applications C++. L'évaluation du contenu d'un std::map (par exemple) requiert de connaître la disposition du type. D'autre part, l'opérateur d'accès au tableau [] peut ne pas être disponible pour le débogueur s'il n'est jamais appelé dans le code ou s'il est toujours inline et donc par conséquent, non appelable. Des problèmes similaires existent pour d'autres types, y compris pour les chaînes, et parfois même pour vos propres types.
Vous pouvez y remédier en utilisant des formateurs. Un formateur est un petit script Python qui aide à déboguer un type particulier. RAD Studio est livré avec des formateurs pour les types communs. Vous pouvez toutefois ajouter des formateurs personnalisés pour vos types.
Les formateurs suivants sont fournis pour les types STL et Delphi.
* std::string and std::wstring * String (UnicodeString), AnsiString, UTF8String, WideString. * std::vector * std::deque * std::stack * std::map * std::shared_ptr
Formateurs personnalisés
Pour ajouter votre propre formateur, créez un nouveau fichier python et modifiez le fichier bin\Windows\lldb\.lldbinit de façon à ce qu'il contienne une ligne faisant référence à votre nouveau script Python. Vous trouverez plus d'informations sur le codage des formateurs personnalisés ici :
- LLDB’s formatting documentation
- How to extend LLDB to provide a better debugging experience
- This Stack Overflow question about writing a custom data formatter
C++ Builder Windows 64 bits
Le compilateur C++Builder Windows 64 bits (BCC64) génère des informations de débogage au format DWARF, différent du format utilisé par BCC32 et BCCOSX. Toutefois, en général, le débogage des applications Windows 64 bits est similaire au débogage des applications C++ Windows 32 bits. Il existe quelques différences, comme indiqué ci-dessous :
- Certaines fonctionnalités du débogueur ne sont pas prises en charge. Le débogage des propriétés, clôtures, méthodes de classe et autres extensions du langage Delphi n'est pas actuellement pris en charge.
- Par exemple, sur l'inspecteur d'objets, les onglets Méthodes et Propriétés ne sont pas affichés pour les applications C++ Windows 64 bits.
- Unicode, les pages de codes et la localisation ne sont pas complètement pris en charge.
- Par exemple, Unicode n'est pas pris en charge dans les noms des identificateurs et les pages de codes ne sont pas prises en charge par le débogueur C++ Windows 64 bits.
- Lors de l'évaluation d'un registre Windows 64 bits, le nom du registre doit être préfixé par $, comme par exemple
$rax.- Voir Evaluer/Modifier.
- Les appels de fonctions qui déclenchent des exceptions sont gérés comme suit :
- Si une fonction contient un bloc try/except/catch et qu'une exception OS/SEH ou C++ est déclenchée lors de l'exécution, l'appel de fonction se termine correctement, mais le résultat est non défini ou vaut 0. Dans ce cas, le bloc d'exception interne n'est pas exécuté car l'exception est gérée directement par le débogueur.
- Si une fonction contient un bloc try/except/catch et qu'aucune exception OS/SEH ou de langage n'est déclenchée, l'appel de fonction se termine correctement et le résultat est correct, selon la fonction.
Différences relatives à la pile d'appels
L'affichage de certaines valeurs peut être différent dans les évaluateurs 32 bits et 64 bits. Par exemple, la pile d'appels est affichée sans paramètre de fonction et sans valeur.
La pile d'appels contient typiquement deux copies de chaque constructeur et destructeur. Par exemple, la pile d'appels peut contenir :
:0000000000401244 ; MyClass::~MyClass
:0000000000401229 ; MyClass::~MyClass
:0000000000401187 ; main
:000000000040ef90 ; _startup
http://stackoverflow.com/questions/6921295/dual-emission-of-constructor-symbols.}}
Réduction de la consommation mémoire du lieur grâce à Split Dwarf
{{Note| Split DWARF est uniquement pris en charge sur C++ Windows 64 bits. Cette fonctionnalité réduit la quantité de données à traiter, ce qui entraîne une réduction des erreurs du lieur. Pour plus d’informations sur la gestion des erreurs relatives au lieur, voir Gestion des erreurs de mémoire insuffisante du lieur.
RAD Studio 10.4.2 inclut une nouvelle fonctionnalité permettant de réduire la quantité de données devant être traitée par le lieur, tout particulièrement lors de la liaison des applications construites en mode débogage. Cette fonctionnalité appelée DWARF répartit les informations de débogage dans un fichier .dwo distinct (objet DWARF) parallèlement au fichier objet normal contenant le code compilé. Comme le lieur ne lie que le code exécutable et de petites quantité d'informations, la consommation de mémoire est réduite.
Activation de Split DWARF dans l'EDI ou msbuild
Ouvrez la boîte de dialogue Options de votre projet C++. Allez à Construction > Compilateur C++ > Débogueur et assurez-vous que la plate-forme cible est définie sur l'une des cibles Windows 64 bits.
- Activez la case à cocher "Utiliser Split DWARF".
- Indiquez un dossier pour les fichiers des informations de débogage dans le champ "Répertoire de sortie DWO". Vous devez indiquer un chemin absolu (cela ne peut pas être un chemin relatif ou un chemin utilisant des variables d'environnement).
Par exemple, c:\myproject\win64debug est correct mais ..\win64debug ne l'est pas.
Pour désactiver cette fonctionnalité, décochez la case dans Options de projet > Construction > Compilateur C++ > Débogage. Ces paramètres seront utilisés lors de la construction depuis l'EDI ou avec msbuild sur la ligne de commande.
Activation de Split DWARF depuis la ligne de commande
Pour activer manuellement Split DWARF sur un build exécuté depuis la ligne de commande, par exemple avec BCC64 :
1. Spécifiez le paramètre Split DWARF sur la ligne de commande du compilateur.
"-enable-split-dwarf" AND "-split-dwarf-file AFilename.dwo"
Le compilateur crée alors le fichier AFilename.dwo et indique l'emplacement de ce fichier .dwo dans le fichier objet .o. Notez toutefois le fichier .dwo ne contient pas les informations de débogage.
2. Utilisez "-dwo-dir <répertoire>" pour spécifier le répertoire dans lequel le compilateur écrit le fichier .dwo. Assurez-vous que c'est un chemin absolu.
3. Exécutez l'outil objcopy.exe sur le fichier .o. Cette action provoque la suppression des sections dwarf du fichier objet (.o) normal et les place dans un fichier .dwo distinct. Cela doit être effectué pour chaque objet (fichier .o) et correspondre au nom que vous avez spécifié à l'étape 1.
objcopy --split-dwo=AFilename.dwo AFilename.o
4. Pour finir, effectuez la liaison des fichiers .o afin de créer votre EXE ou DLL comme vous le feriez normalement (cette étape n'est pas modifiée). Les fichiers seront plus petits que d'habitude car ils contiennent moins d'informations de débogage. Chaque objet contient le nom et l'emplacement du fichier .dwo. Comme décrit à l'étape 2, l'emplacement correspond à votre propre machine et doit être un chemin absolu.
Problème de chargement des informations de débogage lors de l'utilisation de Split DWARF
Lorsque vous utilisez Split-Dwarf pour le débogage Win64, les fichiers source qui ne se trouvent pas dans le même répertoire que le fichier projet peuvent recevoir des informations de répertoire incorrectes générées dans le fichier objet. Cela signifie que les symboles contenus dans ces fichiers (types, variables locales et paramètres) ne seront pas disponibles. Ce comportement peut être remarqué lors du débogage. En effet, les points bleus qui apparaissent dans l'éditeur pour indiquer les numéros de ligne sont visibles. Vous pourrez placer un point d'arrêt mais ne serez pas en mesure d'évaluer ou d'inspecter des expressions ou des symboles.
Pour contourner ce problème, spécifiez un chemin absolu dans le champ "Répertoire de sortie DWO" dans la page des options de projet Compilateur C++ > Débogage > Utiliser Split Dwarf ou utilisez l'option -dwo-dir si vous construisez depuis la ligne de commande. Voir ci-dessus pour des informations sur ces paramètres.
Evaluation d'appels de fonction tels que strcmp()
L'évaluation d'un appel de fonction tel que strcmp(str, "ABC") peut renvoyer une erreur comme suit :
#include <system.hpp>
int main()
{
char *str = "ABC";
return strcmp(str, "ABC");
}
error: 'strcmp' has unknown return type; cast the call to its declared return type
error: 1 errors parsing expression
Dans la fenêtre Evaluer/Modifier, vous devez transtyper le type de retour pour strcmp() :
(int) strcmp(str, "ABC");
Voir strcmp, _mbscmp, wcscmp.
Voir aussi
- Présentation du débogage
- Comment utiliser le débogueur
- Débogage des applications multi-périphériques
- Différences C++ Builder Windows 64 bits
- Gestion des erreurs de mémoire insuffisante du lieur
- Mise à niveau des projets C++ existants vers Windows 64 bits
- Compilateurs C++ plus stricts (compilateurs C++ améliorés par Clang)
- Evaluer/Modifier
- Extensions des fichiers générés par RAD Studio