Sviluppo software

Linux embedded 5/5: configurare l'ambiente di sviluppo per il debug remoto e l'uso delle Qt embedded

Questo articolo fa parte della serie:

In questo articolo analizziamo come effettuare il debug remoto di una semplice applicazione, prima utilizzando la riga di comando e poi utilizzando l'ambiente di sviluppo delle Qt, ovvero il Qt Creator.


Debug remoto con gdbserver#

Partiamo provando a debuggare una semplice applicazione di esempio. Per capire bene cosa avviene, prima è meglio provare utilizzando direttamente la riga di comando.

Per prima cosa scriviamo il file prova.c contenente il seguente codice:


#include <stdlib.h>
#include <stdio.h>
int main()
{ printf("Questa è una prova \n"); return 0;
}

Compiliamo il sorgente con il cross compilatore (nell'esempio seguente si ipotizza che il target utilizzi un processore ARM; abbiamo visto come installare la toolchain di cross-compilazione nell'articolo Linux Embedded 3/5 - Toolchain di cross-compilazione e compilazione di U-Boot e del Kernel Linux ).


computer_host# arm-linux-gcc -o prova prova.c

Copiamo l'eseguibile prova sulla scheda embedded ed eseguiamolo con il comando:


scheda_target# ./prova
Questa è una prova
scheda_target#

Possiamo quindi provare ad effettuare il debug remoto dell'applicazione creata, questo vuol dire che dal sistema host si effettuerà il debug dell'applicazione in esecuzione sulla scheda target. Per farlo si utilizza il programma gdbserver utilizzando la connessione di rete. Per questo motivo sia la scheda target che il sistema host devono essere in rete e le relative schede di rete devono essere configurate con degli indirizzi IP appropriati.

Sul sistema target si deve avviare il gdbserver per il debug della nostra applicazione prova in modo che si metta in ascolto su una porta a nostra scelta ,come ad esempio 4444, e sull'IP della scheda embedded (nell'esempio 192.168.0.5).


scheda_target# gdbserver 192.168.0.5:4444 prova
Process prova created; pid = 1196
Listening on port 4444

A questo punto dal sistema host è possibile avviare il debugger in modo che si colleghi al server che abbiamo avviato sul target e quindi all'applicazione prova posta sotto debug.


computer_host# arm-linux-gdb
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux".
[New Thread 1199]
0x400007b0 in ?? ()
(gdb) target remote 192.168.0.5:4444
A program is being debugged already. Kill it? (y or n) n
Program not killed.
(gdb) file prova
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from /home/giovanni/prova...done.

Come si evince dall'esecuzione precedente il debugger deve avere in locale lo stesso file posto sotto debug sulla scheda, in modo che possa leggere tutte le informazioni di cui ha bisogno da esso (es. la tabella dei simboli).

Una volta connessi all'applicazione da debuggare è possibile impostare i breakpoint, avanzare nel debug o terminarlo. Di seguito un esempio di sessione di debug.


(gdb) break 6
Breakpoint 1 at 0x8390: file prova.c, line 6.
(gdb) continue
Continuing.
Breakpoint 1, main () at prova.c:6
6 printf("Questa è una prova \n");
(gdb) step
(gdb) continue
Continuing.
Program exited with code 00.
(gdb) quit

Utilizzo delle Qt Embedded#

Tra i vari pacchetti resi disponibili da Buildroot c'è il supporto alle Qt Embedded. Per prima cosa quindi va realizzato un filesystem per il sistema target che contenga tutte le librerie delle Qt Embedded. Per farlo basta, dalla directory di buildroot, avviare il menù di configurazione con il comando make menuconfig e abilitare il supporto alle Qt che si trova nella voce di menù: Package Selection for the target -> Graphic libraries and applications (graphic/text) -> Qt.

Molto importante abilitare i Graphics, Mouse e Keyboard driver e il supporto ai font con freetype2, specialmente per applicazioni multilingua con caratteri esotici. Tra i graphics driver da abilitare c'è come minimo il "Linux framebuffer" che consente di accedere direttamente al buffer della scheda video.

Configurato Buildroot si procede al solito modo a creare l'immagine del filesystem per il sistema target. Questo argomento è già stato trattato nell'articolo Linux Embedded 4/5 - Creare l'immagine del filesystem con Buildroot.

Qt Creator#

A questo punto non resta che installare e configurare le Qt comprensive di ambiente di sviluppo sul sistema host. Per ovvie ragioni si consiglia sul sistema host di installare una versione delle Qt uguale a quella presente sul target. Al momento di scrivere questo articolo la versione più utilizzata è la 4.8.

Dopo aver avviato il Qt Creator bisogna andare nella voce di menù Tools -> Options e aggiungere i riferimenti alle Qt cross compilate per l'ambiente target.

Oltre al riferimento alle Qt bisogna aggiungere anche la toolchain di cross compilazione.

Fatto ciò l'IDE è configurato e si può procedere alla creazione del proprio progetto con le Qt. Ad esempio dal menù File -> New file or project… si può scegliere di realizzare una Qt Gui Application dai template presenti sotto Qt Widget Project.

Avendo aggiunto sia la toolchain di cross compilazione che quella nativa è possibile compilare la stessa applicazione sia per il sistema host, ma anche per il sistema target. Per ogni versione e piattaforma i relativi file di compilazione e gli eseguibili prodotti saranno posizionati in directory diverse.

Infine per effettuare il debug remoto si può richiamare dal menù la funzione "Start and Attach to Remote application…".

Lo start script è uno script creato su misura che ha il compito di copiare l'eseguibile appena cross-compilato sul sistema target e fare in modo che sul sistema target venga avviato per mezzo del gdbserver.

ATTENZIONE: SERVIZIO DI CONSULENZA SOSPESO#

Non offriamo più questo tipo di consulenza.

Questo articolo resta per documentare un'attività che abbiamo svolto in passato, ma che non facciamo più.

Autore: Giovanni Chiodi
Senior software developer con più di 10 anni di esperienza nello sviluppo di soluzioni web based, enterprise, su misura. Dal 2011 socio fondatore di Garda Informatica Snc condivide questa avventura col fratello Lorenzo.

Promemoria sui Cookie e sulla Privacy

Leggi l'informativa
closeIcona closesearchIcona searchmore vertIcona more vertmenuIcona menu