Debug target da Qt Creator su host

[Antonino Battaglia]

Ciao a tutti,
mi scuso innanzitutto nel caso in cui non sia la sezione appropriata per la mia domanda, ma mi sembra la piu pertinente.
Ho appena finito di compilare kernel e qt-embedded per il mio target ossia una PDK Freescale con iMX35 e display 7" touchscreen,
li ho trasferiti sulla scheda e ho fatto girare un po di esempi e demo per vedere che sia andato tutto a buon fine.

Il mio progetto Qt prevedera' in parte un'interfaccia grafica e in parte delle funzionalita' che implementero' con funzioni C++,
e che vorrei debuggare con qualcosa in piu' che dei printf.

Una volta creato il progetto sull' host (il mio notebook con linux, Qt 4.7.1 e Qt creator 2.1), compilato e transferito sul target,
mi chiedo se sia possibile debuggurlo direttamente dall'ambiente di debug fornito da Qt creator.
Cioe' vorrei far girare il progetto sul target e vedere le info e variabili sul mio PC come se stessi debuggando un progetto che gira sul mio stesso pc.

Vorrei non utilizzare Eclipse ma direttamente Qt per Linux o Windows.

Se qualcuno ha qualche info da darmi su come fare o link utili, sono ben accetti. Grazie in anticipo!!

Ciao,
Nino

[rugginoso]

Se hai accesso seriale o via rete e gdb sul target, puoi fare debug da linea di comando.
Penso non sia possibile farlo direttamente da QtCreator.
Ovviamente cerca di sfruttare il più possibile la proprietà di Qt di essere multipiattaforma e fai il normale sviluppo e debug su desktop, e solo quando hai realmente necessita di fallo sul target.

[Antonino Battaglia]

Come immaginavo. Grazie rugginoso per la risposta. Effettivamente procedere come dici tu, per quanto riguarda la parte grafica, va benissimo.
Il problema e' che la scheda target comunichera' con altri dispositivi e reagira' ad eventi esterni. Usera' pins IO, pins analogici, PWM ed SPI.
Per testare le funzionalita' su PC host quindi dovró inventarmi qualcosa, come per esempio una scheda ad hoc per interfacciare il PC
(seriale o usb tra PC e scheda) al mondo esterno che vedrebbe il target (IO, analog IO, PWM, SPI tra scheda ed esterno).
Sviluppare e debuggare il progetto su PC e poi modificarlo per le interfacce reali del target.
Un pó troppo macchinoso forse, ma non so se sará sufficiente il debug da linea di comando quando dovró mettere tanti breakpoint
e vedere l'evoluzione di tante variabili. Appena ho novitá scriveró qualcosa, magari qualcuno avrá la mia stessa necessitá.

Grazie ancora per il supporto. ciao!

[specialk74]

Io utilizzo come debugger per il target gdbserver+insight: magari ci fosse integrato su QtCreator.
Ultimamente mi hanno suggerito un emulatore: softgun.
In teoria puoi emulare 100% la macchina ma devi crearti tutte le periferiche tu.

Bye.

[Antonino Battaglia]

Ciao,

cercando su internet "Remote debugging with Qt Creator" sembra che in realta' sia in qualche modo fattibile.
Utilizzando gdbserver sul target remoto forse e' possibile debuggare direttamente da Qt Creator.

Sono in contatto con un ingegnere Nokia e non mi ha detto che non si puo' fare. Mi ha chiesto se dispongo di gdbserver
e di una connessione seriale o TCP con il PC host. E di contattarlo in caso positivo per darmi spiegazioni/indicazioni.

Vi faro' sapere come va a finire. Nel frattempo ho installato gdbserver sul mio target e gdb 7.2 sull'host.
Qui di seguito la procedura che ho seguito per l'installazione e il test del debug remoto, scopiazzata e riadattata
da questo link: http://hubpages.com/hub/Remote-debuggin ... rget-board.

Sembra funzionare, solo che una volta stabilita la connessione remota ho un warning che non so come interpretare,
(potete vedere piu dettagli sull'output alla fine della sezione del codice)

warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x400007e0 in ?? ()

Sapete che significa e se e' il caso di indagare per risolverlo? Vorrei avere tutto perfettamente funzionante prima
di contattare l'ingegnere Nokia per gli eventuali passi successivi.

Grazie, ciao

Codice: Seleziona tutto

Configure, make and make install for gdb-7.2

>cd /home/elux/MX35/gdb-7.2/
>./configure --target=arm-none-linux-gnueabi --build=i686
>make
>sudo make install

Configure, make and make install for gdbserver
>cd gdb/gdbserver/
>export PATH=$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin
>export CC=arm-none-linux-gnueabi-gcc
>export LD=arm-none-linux-gnueabi-ld
>./configure --build=i686 --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi
>make

Copy gdbserver to target
>sudo cp gdbserver /home/elux/MX35/ltib/rootfs/usr/bin/

Cross-compile and copy to target Hello world
>cd /home/elux/MX35/Test/
>arm-none-linux-gnueabi-gcc -g -Wall -o hello hello.c
>sudo cp hello /home/elux/MX35/ltib/rootfs/home/user/

On the target
>gdbserver :4000 hello
Process hello created; pid = 2115
Listening on port 4000
Remote debugging from host 10.10.10.1

On the host
arm-none-linux-gnueabi-gdb hello
GNU gdb (GDB) 7.2
Copyright (C) 2010 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=i686 --target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/elux/MX35/Test/hello...done.
(gdb) target remote 10.10.10.2:4000
Remote debugging using 10.10.10.2:4000
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0x400007e0 in ?? ()
break main
Cannot access memory at address 0x0
Breakpoint 1 at 0x835c: file hello.c, line 4.
(gdb)


[specialk74]

Il Warning che ti viene dato riguarda gdb che non riesce a caricare la tabella dei simboli della librearia che utilizza il tuo programma.
Su Linux riescia capire di quale librearia si tratta leggendo /proc/<PID>/maps sul target quando il tuo programma sta girando e confrontare l'indirizzo fornito da gdb.
Gli puoi dire a gdb qualè la "root" dove scovare le librerie ma per "debuggarle" devi comunque utilizzare il paramtro -g del compilatore e non "stripparle".
Comunque anche se ti fornisce questo warning, il tuo programma riesci "tranquillamente a debuggarlo". Prova ad utilizzare insight che è anche grafico e, per me, leggermente più intuitivo.
Se ci riesci fammi sapere perchè anch'io ci sto sbattendo la testa da parecchio tempo.

Bye.

[giorgio]

Io riesco a "debbagare" il targhet direttamente dall'host senza grossi problemi utilizzando Eclipse/Galileo + plugin per integrare QT + gdb e gdbserver.
Posso debbagare in grafica, mettere breakpoints, valutare variabili, vedere la memoria etc...
Avevo provato a fare la stessa cosa utilizzando il Qt Creator ma non ci sono riuscito.

L'errore che ottieni quando avvi il gdb potrebbe essere dovuto al fatto che il programma tenta di caricare all'avvio delle librerie non compilate per ARM.
Io ho avuto un problema simile.

Nel mio caso l'ho risolto creando il file .gdbinit ( che il gdb carica all'avvio ) ed aggiungendo la seguente riga:
set solib-absolute-prefix /path/rootfs

Dove rootfs è la directory ( sul mio PC ) da cui la scheda targhet da il boot tramite nfs e che contiene tutto il file system e le librerie compilate correttamente per ARM.
Controlla la documentazione freescale per la configurazione dell'ambiente di sviluppo oppure visita il sito http://www.imxdev.org

[rugginoso]

Amici è proprio un bel thread questo.

[Antonino Battaglia]

Ciao a tutti,
scusatemi se c'ho messo un po' a scrivere. Innanzitutto grazie per i vostri consigli che sono stati molto preziosi.
Sono riuscito a debuggare il target direttamente da Qt e dopo tutto non e' stato cosi difficile.

Prima di entrare nel debug, vorrei pero' descrivere come ho impostato il sistema per poter compilare il progetto
per host e target. Io c'ho perso piu' tempo di quanto pensavo per cui magari a qualcuno puo' essere utile.

Il target e' una PDK freescale iMX35. Freescale mi ha fornito ltib (Linux Target Image Builder) e una patch per Qt,
in modo da poter cross-compilare il kernel, file system, Qt 4.7.1 per il target. Ho quindi sul mio PC una cartella ../ltib/rootfs
che esporto sul target e una cartella ../ltib/rpm/BUILD/qt-everywhere-opensource-src-4.7.1
Dal Synaptic di ubuntu ho fatto il download di qt 4.7.1 e Qt creator 2.1RC per l'host.

In questo modo in QtCreator -> Options -> Qt4 ho due versioni di qmake:



A questo posso creare un progetto "Qt Quick application" selezionando entrambi i qmake. In Projects -> Build Settings
ho quindi 2 configurazioni (debug e release) che mi permettono di compilare il progetto con Qt in PATH per il mio PC
e creano il file eseguibile in /nomeprogetto-build-desktop.
Quindi creo altre due configurazioni che chiamo Arm Debug e Arm Release selezionando la versione di Qt
evidenziata nell'immagine sopra. Come Build Directory scelgo
../ltib/rpm/BUILD/qt-everywhere-opensource-src-4.7.1/projects/nomeprogetto-build-arm.

Nel mio caso, la scelta di questa directory e' fondamentale. Per qualche strana impostazione che non so dove sia,
se scelgo di creare il file compilato per arm in una sottartella della mia installazione di Qt Creator
(per esempio /home/xxxx/qtcreator-2.0.94/projects/nomeprogetto-build-arm) mi da errore su qatomic_i386,
come se cercasse files per l'host e non per il target. Cmq adesso posso compilare per host e target a scelta.

Premesso che abbiate gdbserver e gdb su target e host, una volta passato il file eseguibile su target, per deguggare e' sufficiente:

- su target: > gdbserver :4000 nomeprogetto

- su host:



e poi Debug -> Start Dugugging -> Start and attach to remote application



et voila!!! potete mettere breakpoint e vedere le variabili da remoto.

Per cortesia provatelo, datemi commenti/feedback, e magari un parere se e' meglio debuggare da Qt creator o da eclipse.

Un saluto a tutti, ciao

[enaud]

Puoi ripostare le immagini che non si vedono più?
grazie..