Debugging avanzato per Linux embedded

Debugging avanzato per Linux embedded

Il debugging avanzato per linux embedded diventa semplice con i Trace32 di Lauterbach. Trace32 è una famiglia di debugger che supporta le tecnologie come JTAG, BDM, NEXUS o ETM con debugger integrati, trace software e hardware, sistemi di analizzatori logici per più di 3500 core e CPU con 250 famiglie come ARM9, ARM11, Cortex, PowerPC, MIPS, TriCore, ecc.

Trace32 è un sistema universale progettato specificatamente per fornire un ambiente completo integrato con le prestazioni e la flessibilità che fissano nuovi standard per i progettisti che si occupano di debugging avanzato su sistemi ARM/Linux.
La necessità di utilizzare architetture di CPU multicore deriva dall’intento di capire e risolvere i problemi di consumo energetico e conseguente dissipazione di calore, che nascono quando la frequenza di lavoro di una CPU a singolo core aumenta. Poi il desiderio tecnologico di ridurre la geometria di un chip fa aumentare i problemi di progetto, causati da effetti parassiti come effetti capacitivi e correnti di dispersione.
 

Debugging avanzato per Linux EmbeddedIl 19 Aprile a Milano si terrà un seminario proprio sulle tecniche avanzate
di debugging per sistemi ARM/Linux.
Il seminario è riservato alle aziende, questo il programma ed il modulo di registrazione: tecniche avanzate di debug per sistemi multicore [PDF]

 

Debugging multicore avanzato: dentro il problema!

Un primo passo per risolvere questi problemi è definire nuove architetture di CPU con superpipeline oppure di tipo superscalare. Nell’architettura di CPU con superpipeline si riduce ogni stadio della pipeline in unità più piccole. Nella seconda, di tipo superscalare, si aumenta il numero di pipeline facendole lavorare in parallelo. Ma questo porta altri problemi, in particolare riguardo alle condizioni di stallo della pipeline e della complessità della sincronizzazione.

Un altro "trend" è quello di aumentare le unità ALU (logico-aritmetiche), rendendo così possibile l’elaborazione contemporanea di più istruzioni, ciascuna delle quali opera su dati diversi. In questo caso parliamo di architettura MIMD (multiple instruction multiple data). L’architettura MIMD a singolo core risulta comunque molto complessa a livello progettuale. La soluzione adottata per risolvere questi problemi è quella di sviluppare architetture multicore vere e proprie, realizzando così diverse unità più piccole al posto di una sola più grande.
Così la complessità di progetto si sposta dal singolo core al sistema di comunicazione e di bilanciamento del carico di elaborazione dei core.

Dal punto di vista energetico, la disponibilità di più core permette anche lo spegnimento temporaneo delle unità meno attive. Questo risulta molto più semplice rispetto allo spegnimento di singoli circuiti di un solo core. In più i core di una CPU possono anche essere realizzati in modo asimmetrico, dedicando ogni singolo core a un compito specifico (è frequente il caso in cui una CPU multicore sia composta da un’unità microcontrollore e da un processore DSP). Se il bilanciamento del carico di lavoro non si è realizzato a livello hardware, la potenza elaborativa delle architetture multicore può essere sfruttata solo se esiste un supporto da parte di un sistema operativo.

Il multiprocessing può quindi essere classificato in due modi:

    - sono possibili soluzioni asimmetriche (AMP) in cui l’assegnamento dei task a un singolo core è definito univocamente in fase progettuale;

    - oppure soluzioni simmetriche (SMP, symmetrical multiprocessing) in cui ogni task è assegnato a un core dinamicamente, da parte di un sistema operativo SMP, sulla base di politiche di assegnamento definite nel sistema operativo stesso. In questo caso tutti i core devono essere dello stesso tipo.

Debugging avanzato: AMP e SMP

Lauterbach supporta il debug di sistemi asymmetrical multiprocessing (AMP) mediante istanze separate del software Trace32, una per ogni core.
Per il debug di sistemi AMP viene avviata una singola istanza di TRACE32 per ogni core.
Per il debug di sistemi symmetrical multiprocessing SMP, Lauterbach fornisce una singola istanza del software TRACE32 in grado di controllare tutti i core. L’interfaccia utente mostra le informazioni d’interesse per il debug di un’applicazione, riconoscendo in modo automatico il core su cui è allocata.

Per il debug di sistemi SMP una singola istanza di TRACE32 controlla tutti i core.

Trace AMP e SMP

Il trace real time di un’applicazione permette di capire in modo rapido e sistematico condizioni di malfunzionamento particolarmente complesse, che si verificano solo in condizioni runtime. È anche possibile ottenere informazioni statistiche, come ad esempio l’analisi di copertura del codice eseguito e (avendo a disposizione anche informazioni sul tempo di esecuzione) il profiling della durata delle singole funzioni, in modo da verificare la corrispondenza con eventuali requisiti temporali. 

Linux awareness: debug con TRACE32

Il riconoscimento delle strutture dati rilevanti di un sistema operativo e dei suoi meccanismi di gestione delle risorse (awareness) permette a un debugger di offrire all’utente funzionalità avanzate di controllo del software.
Nel caso di Linux utilizzato su sistemi embedded, i debugger Lauterbach forniscono un’integrazione molto sofisticata con il sistema operativo, in grado di mostrare le condizioni di utilizzo delle principali risorse allocate.
Per garantire queste funzionalità, l’awareness riconosce la configurazione dell’MMU del processore, sapendo che Linux opera in uno spazio di memoria virtuale.

Si noti che il meccanismo di demand paging di Linux comporta che un’applicazione possa essere fisicamente non presente in memoria, fintanto che le singole pagine contenenti istruzioni o dati non vengano richieste per l’esecuzione. Il supporto a Linux in Lauterbach permette di effettuare il debug di un processo utente a partire dal suo avvio. Se il processo utilizza librerie dinamiche (shared objects) Linux le carica nello spazio di indirizzamento del processo. Occorre tenere presente che anche le librerie dinamiche vengono caricate da Linux nel momento in cui le loro istruzioni sono utilizzate per la prima volta.

Con i debugger Lauterbach è inoltre possibile il debug dei threads che compongono un processo. In questo caso è sufficiente caricare una sola volta le informazioni simboliche associate al processo. Il kernel di Linux è compilato in modo da consentire il collegamento di moduli aggiuntivi, che possono essere caricati dinamicamente. Con Lauterbach è possibile effettuare il debug di un modulo a partire dalle funzioni di inizializzazione.
È inoltre facilitato il debug delle eccezioni di segmentation violation, mediante l’assegnamento dei breakpoint necessari per identificare l’eccezione e la possibilità di caricare temporaneamente i registri del processore con lo stato macchina che ha provocato l’eccezione, così da facilitare l’analisi del problema. Al momento in cui l’esecuzione viene ripresa, vengono ripristinati i registri originali.
È anche possibile associare dei breakpoint a un singolo task ed eseguire per un singolo task il trace del flusso di programma.
Nel caso in cui il processore fornisca funzionalità di trace dei dati, è possibile tracciare il cambio di contesto dei singoli task, con il supporto del sistema operativo.

L’awareness di Linux permette di esaminare l’utilizzo delle risorse del sistema operativo, come ad esempio i task in esecuzione

Android

Nelle applicazioni Android, in ambito embedded, esistono molte situazioni in cui non è sufficiente eseguire il debug della sola applicazione Java. Si tratta ad esempio di casi in cui è necessario modificare dei componenti di sistema, come lo stack di rete, oppure analizzare l’interazione fra un’applicazione e un driver di basso livello. Si pensi anche a casi di analisi post mortem, in cui è necessario studiare lo stato di un sistema che ha appena subìto un crash inatteso, per ricostruirne le cause. È inoltre comprensibile come risulti difficile integrare in uno stesso ambiente il debug del codice nativo e il debug del codice Java. Si tratta di due tipi diversi di codice, eseguiti diversamente fra loro e non riconducibili l’uno all’altro in modo elementare. I debugger Lauterbach forniscono un ambiente che permette il cosiddetto stop mode debugging, ovvero la possibilità di fermare il processore che esegue la macchina fisica, congelando dunque in uno stato ben definito la piattaforma che contiene il sistema operativo e le applicazioni in esecuzione, in modo da consentirne un’analisi tramite il debugger. Tutte le soluzioni per il debugging dei sistemi Android, verranno presentate al seminario.

Partecipa al seminario del 19 Aprile a Milano. Il seminario, riservato alle aziende, è gratuito. Scarica il programma in PDF

25 Comments

  1. Francesco12-92 6 aprile 2011
  2. Giovanni Giomini Figliozzi 6 aprile 2011
  3. FlyTeo 6 aprile 2011
  4. Giovanni Giomini Figliozzi 6 aprile 2011
  5. FlyTeo 6 aprile 2011
  6. Antonio Mangiardi 6 aprile 2011
  7. Giovanni Giomini Figliozzi 7 aprile 2011
  8. Antonio Mangiardi 7 aprile 2011
  9. FlyTeo 4 aprile 2011
  10. slovati 4 aprile 2011
  11. FlyTeo 7 aprile 2011
  12. Antonio Mangiardi 7 aprile 2011
  13. Giovanni Giomini Figliozzi 7 aprile 2011
  14. Antonio Mangiardi 4 aprile 2011
  15. Antonio Mangiardi 7 aprile 2011
  16. Giovanni Giomini Figliozzi 7 aprile 2011
  17. Antonio Mangiardi 7 aprile 2011
  18. Fabrizio87 4 aprile 2011
  19. Giovanni Giomini Figliozzi 4 aprile 2011
  20. FlyTeo 8 aprile 2011
  21. Antonio Mangiardi 8 aprile 2011
  22. linus 5 aprile 2011
  23. FlyTeo 8 aprile 2011
  24. Giovanni Giomini Figliozzi 5 aprile 2011
  25. FlyTeo 5 aprile 2011

Leave a Reply