Auparavant, dans cet article (https://qiita.com/take-iwiw/items/46119bb7d41c6030d34f), j'ai facilement construit un environnement de développement C / C ++ pour Raspeye. À ce moment, toute la construction et le débogage ont été effectués sur Raspeye.
Cette fois, je décrirai la compilation croisée sur Ubuntu et la méthode de débogage à distance utilisant gdbserver. Enfin, vous pourrez déboguer Raspai par opération GUI à partir de VS Code sur le PC hôte. Le débogage est désormais possible à partir d'Ubuntu et de Windows.
Bien que cet article soit destiné à Raspeye, je pense qu'il peut également être appliqué au développement croisé Linux embarqué général.
En gros, vous ne devez le faire qu'une seule fois.
Terminal sur Ubuntu
sudo apt-get update
sudo apt-get install build-essential libncurses-dev git git-core
mkdir ~/raspberry
cd ~/raspberry
git clone https://github.com/raspberrypi/tools
Essayez de créer ~ / work / pi / sample01 / sample01.cpp comme indiqué ci-dessous.
sample01.cpp
#include <stdio.h>
int main()
{
printf("Hello World\n");
for (int i = 0; i < 10; i++)
printf("i = %d\n", i);
return 0;
}
Terminal sur Ubuntu
mkdir ~/work/pi/sample01 && cd ~/work/pi/sample01
code sample01.cpp &
ARCH=arm ~/raspberry/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ sample01.cpp
# ARCH=arm ~/raspberry/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++ sample01.cpp
scp a.out [email protected]:.
Vous pouvez exécuter a.out transféré par la dernière commande scp sur la tarte aux râpes.
Pour un environnement 32 bits, raspberry / tools / arm-bcm2708 / gcc-linaro-arm-linux-gnueabihf-raspbian / bin
peut être mieux.
J'ai beaucoup fait référence à cet article. (https://qiita.com/tetsu_koba/items/ebbac47e3fb43c86f412). Merci beaucoup.
En gros, vous ne devez le faire qu'une seule fois.
Terminal sur Raspeye
sudo apt-get install gdbserver
Terminal sur Ubuntu
mkdir ~/temp && cd ~/temp
wget http://ftp.jaist.ac.jp/pub/GNU/gdb/gdb-8.0.1.tar.gz
tar xf gdb-8.0.1.tar.gz
cd gdb-8.0.1
mkdir build && cd build
sudo apt-get install libexpat1-dev expat
../configure --target=arm-buildroot-linux-gnueabi --with-expat
make -j4
sudo make install
Terminal sur Raspeye
gdbserver --multi :5555
Créez le fichier suivant (~ / work / pi / sample01 / gdb_load) au même endroit que le fichier d'exécution que vous souhaitez déboguer.
script d'exécution automatique gdb
target extended-remote 192.168.1.89:5555
file ./a.out
remote put ./a.out /home/pi/a.out
set remote exec-file /home/pi/a.out
start
Exécutez la commande suivante avec le même chemin que gdb_load et a.out pour démarrer le débogage. Les informations de débogage sont envoyées au terminal côté Ubuntu, et une sortie telle que printf est sortie vers le terminal côté Raspeye.
Terminal sur Ubuntu
arm-buildroot-linux-gnueabi-gdb -x gdb_load
#↓ est l'invite dans gdb
>>> n
Fondamentalement, gdbserver démarré du côté Raspeye peut toujours être démarré. Par conséquent, aucune opération n'est requise du côté Raspeye.
Dans le terminal gdb côté Ubuntu, faites q
et exécutez à nouveau gdb pour redémarrer.
Je pense que le débogage avec la commande gdb est inefficace à moins que vous ne soyez très familier avec elle. Vous permet de déboguer avec l'interface graphique de VisualStudio Code. Comme pour le développement d'applications générales, les paramètres d'exécution d'étape et de pointeur d'arrêt peuvent être définis à partir de l'interface graphique afin que les variables de la portée puissent être référencées automatiquement.
Ouvrez le répertoire ~ / work / pi / sample01 /
à partir de VS Code et appuyez sur F5 pour essayer de déboguer. Après cela, il vous sera demandé de créer un paramètre de débogage, alors sélectionnez C ++ (GDB / LLDB).
Launch.json sera ouvert, alors modifiez-le comme suit.
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/a.out", //★ Modifier
"args": [],
"stopAtEntry": true, //★ Modifier(comme vous voulez)
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "arm-buildroot-linux-gnueabi-gdb", //★ Ajout
"setupCommands": [ //★ Ajout
{"text": "target extended-remote 192.168.1.89:5555"},
{"text": "file a.out"},
{"text": "remote put a.out /home/pi/a.out"},
{"text": "set remote exec-file /home/pi/a.out"}
]
}
]
}
Appuyez à nouveau sur F5 pour démarrer le débogage. Après cela, lors du débogage du projet dans ce répertoire, appuyez simplement sur la touche F5. Les sorties telles que printf sont sorties vers le terminal du côté Raspeye.
Généralement, si la cible est Linux, je pense que l'environnement de développement HOST est également Linux. Cependant, pour une raison quelconque, vous souhaitez souvent modifier ou déboguer votre code sur un PC Windows. (Par exemple, je pense que c'est une pratique courante de construire sur un serveur de build Linux, de télécharger le binaire construit sur le PC Windows du développeur et de l'écrire sur la cible). Dans un tel environnement, je pense qu'il est gênant d'installer Ubuntu uniquement pour le débogage, donc je le rendrai également possible sur Windows. Utilisez MSYS2 pour le fonctionnement du terminal.
Créez un binaire gdb pour ARM avec la commande suivante.
Terminal sur MSYS
mkdir ~/temp && cd ~/temp
wget http://ftp.jaist.ac.jp/pub/GNU/gdb/gdb-8.0.1.tar.gz
tar xf gdb-8.0.1.tar.gz
cd gdb-8.0.1
mkdir build && cd build
../configure --target=arm-buildroot-linux-gnueabi --with-expat
make -j4
make install
_ Note
La compilation a réussi une fois, mais après avoir installé python (pacman -S python2
) et fait diverses choses, je n'ai pas pu reconstruire. .. .. _
C'est fondamentalement exactement la même chose que j'ai fait sur Ubuntu. Supposons que le code source et les binaires ARM préconstruits se trouvent dans C: / Users / tak / Desktop / win_share / sample01 /
.
Modifiez launch.json comme suit.
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/a.out", //★ Modifier
"args": [],
"stopAtEntry": true, //★ Modifier(comme vous voulez)
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:/msys64/mingw64/bin/arm-buildroot-linux-gnueabi-gdb.exe", //★ Ajout
"setupCommands": [ //★ Ajout
{"text": "target extended-remote 192.168.1.89:5555"},
{"text": "file C:/Users/tak/Desktop/win_share/sample01/a.out"},
{"text": "remote put C:/Users/tak/Desktop/win_share/sample01/a.out /home/pi/a.out"},
{"text": "set remote exec-file /home/pi/a.out"}
]
}
]
}
Veuillez noter que le gdb pour ARM que vous avez créé vous-même n'a pas de chemin sur Windows, vous devez donc spécifier le chemin complet. J'ai également dû spécifier le chemin complet du fichier binaire à charger. J'ai essayé d'utiliser $ {workspaceFolder}
pour voir s'il pouvait être omis, mais cela n'a pas fonctionné.
En appuyant à nouveau sur la touche F5, vous pouvez déboguer comme indiqué ci-dessous.
Étant donné que mon PC principal est Windows, je ne construis qu'avec Rasppie et je débogue avec VSCode sous Windows.
g++ -O0 -g3 sample01.cpp
monitor exit
depuis l'invite gdb du côté hôte.
--Lors de la spécification de l'emplacement de la bibliothèque partagée, set sysroot. /
--Si la configuration source et le chemin sont différents entre l'environnement de construction et l'environnement d'exécution gdb, set substitute-path from-path to-path
«Même si l'environnement est différent, cela a bien fonctionné pour le moment. S'il y a un chemin relatif, cela semble être un peu correct.Recommended Posts