path: root/tde-i18n-it/docs/tdevelop/tdevelop/debugger.docbook

<chapter id="debugger">
<title
>L'interfaccia del debugger</title>
<indexterm zone="debugger"
><primary
>debugger</primary
></indexterm>

<para
>Per i linguaggi C e C++, KDevelop contiene un debugger interno che è direttamente integrato nell'editor. Tecnicamente è implementato come un frontend che usa <application
>gdb</application
> (portable &GNU; debugger) attraverso una pipe. Il debugger può essere avviato in diversi modi: </para>

<itemizedlist>
<listitem>
<para
>Con <menuchoice
><guimenu
>Debug</guimenu
><guimenuitem
>Avvia</guimenuitem
></menuchoice
>, il programma principale del proprio progetto viene caricato nel debugger. </para>
</listitem>

<listitem>
<para
>Usando <menuchoice
><guimenu
>Debug</guimenu
><guimenuitem
>Esamina il file core...</guimenuitem
></menuchoice
> viene caricato in memoria un file core che è stato generato dal kernel del sistema operativo quando il programma è andato in crash (la generazione di file core potrebbe essere disattivata sul proprio sistema, vedere <application
>ulimit(1)</application
>). Questo è utile per un'analisi post-mortem del programma. </para>
</listitem>

<listitem>
<para
>Con <menuchoice
><guimenu
>Debug</guimenu
><guimenuitem
>Collega al processo</guimenuitem
></menuchoice
> si usa il debugger su un programma già in esecuzione. Verrà mostrata una lista di processi da dove si può selezionare quello che dovrà essere supervisionato dal debugger. </para>
</listitem>

<listitem>
<para
>Notare che questo debug è possibile se il proprio progetto è stato compilato con l'attivazione delle informazioni di debug. Possono essere attivate nella finestra di dialogo <guibutton
>Opzioni compilatore</guibutton
>. Quando questa opzione è attivata il compilatore genera dati aggiuntivi che permettono al debugger di associare i nomi dei file e numeri di linea con gli indirizzi nel file eseguibile. </para>
</listitem>
</itemizedlist>

<para
>Il frontend del debugger fornisce diverse viste <quote
>nel</quote
> processo: </para>

<para
>Se si tenta di effettuare il debug di un progetto che non ha le informazioni di debug si riceverà il messaggio <computeroutput
>Sorgente inesistente...</computeroutput
> nella barra di stato. Se si tenta di impostare un breakpoint, viene visualizzato come <computeroutput
>Pendente (aggiungi)</computeroutput
> nella finestra dei breakpoint (vedere sotto). </para>

<variablelist>
<varlistentry>
<term
>Variabili</term>
<listitem>
<indexterm zone="debugger"
><primary
>osservare variabili</primary
></indexterm>
<para
>Questa finestra elenca i valori di tutte le variabili locali del punto corrente dell'esecuzione del programma. Esso include le variabili dell'intero stack delle chiamate, &ie; la funzione dove è stato interrotto il processo, la funzione che ha chiamato quella funzione e così via fino a <function
>main()</function
>. </para>

<para
>Un altro ramo di variabili contiene le variabili di osservazione. Si possono configurare quali variabili mostrare qui. Possono essere osservate sia le variabili locali che globali. Si possono aggiungere variabili facendo clic sul pulsante <guibutton
>Aggiungi</guibutton
> o premendo <keycap
>RETURN</keycap
> mentre è selezionata la voce <guilabel
>Espressione da controllare</guilabel
>. Possono essere rimosse nuovamente attraverso il menu contestuale. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Stack del frame</term>
<listitem>
<indexterm zone="debugger"
><primary
>Stack del frame</primary
></indexterm>
<para
>(... da scrivere ...) </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Breakpoint</term>
<listitem>
<indexterm zone="debugger"
><primary
>Breakpoint</primary
></indexterm>
<para
>In questa finestra vengono mostrati e modificati i breakpoint. &tdevelop; usa <application
>GDB</application
>, quindi per capire pienamente le sue funzionalità di debug, è necessario conoscere anche <ulink url="http://www.gnu.org/software/gdb"
>quest'ultimo</ulink
>. </para>

<para
>Se si vuole controllare il codice sorgente, i breakpoint sono definiti nel file <filename
>tdevelop/languages/cpp/debugger/breakpoint.h</filename
>. </para>

<para
>Nel bordo sinistro la finestra presenta vari pulsanti per:</para>

<itemizedlist>
<listitem
><para
>Aggiungere un breakpoint vuoto</para
></listitem>
<listitem
><para
>Modificare il breakpoint selezionato</para
></listitem>
 <listitem
><para
>Eliminare il breakpoint selezionato</para
></listitem>
<listitem
><para
>Rimuovere tutti i breakpoint</para
></listitem>
</itemizedlist>

<para
>La parte principale della finestra è costituita da una tabella con 7 colonne. Ogni linea della tabella rappresenta un breakpoint. Le colonne sono:</para>

<orderedlist>
<listitem
><para
>Casella di selezione</para
></listitem>
<listitem
><para
>Il tipo può essere: Non Valido, File:Linea, Punto di Controllo, Indirizzo, Funzione</para
></listitem>
<listitem
><para
>Stato: i valori possono essere:</para>
<itemizedlist>
  <listitem
><para
>Attivo</para
></listitem>
  <listitem
><para
>Disabilitato: ogni breakpoint può essere <quote
>abilitato</quote
> o <quote
>disabilitato</quote
>; finché non viene abilitato, non ha effetti sul programma.</para
></listitem>
  <listitem
><para
>Pendente (aggiungi): un breakpoint è in questo stato se non è disponibile nessuna informazione di debug. Dalla pagina Info di GDB: <blockquote
><para
>Se una specifica posizione del breakpoint non viene trovata, potrebbe essere all'interno di una libreria condivisa (shared) che non è stata ancora caricata. In questo caso, si può far creare a GDB un breakpoint speciale (noto come <quote
>breakpoint pendente</quote
>) che tenterà di effettuare la propria risoluzione quando verrà caricata la libreria condivisa.</para
> </blockquote
> </para
></listitem>
</itemizedlist>
</listitem>
<listitem
><para
>Pendente (chiaro)</para
></listitem>
<listitem
><para
>Pendente (modifica)</para
></listitem>
<listitem
><para
>Posizione nel formato nomefile:numerolinea</para
></listitem>
<listitem
><para
>Condizione</para
></listitem>
<listitem
><para
>Ignora il conteggio: se esiste un numero <varname
>COUNT</varname
> maggiore di zero, per le prossime <varname
>COUNT</varname
> volte in cui viene raggiunto il breakpoint, l'esecuzione del programma non verrà interrotta; <application
>gdb</application
> non intraprende alcuna azione, a parte decrementare il valore della variabile.</para
></listitem>
<listitem
><para
>Trovati: conta quante volte è stato raggiunto il breakpoint.</para
></listitem>
</orderedlist>


</listitem>
</varlistentry>

<varlistentry>
<term
>Disassembla</term>
<listitem>
<indexterm zone="debugger"
><primary
>disassembla</primary
></indexterm>
<para
>(... da scrivere ...)</para>

</listitem>
</varlistentry>
</variablelist>


<sect1 id="settingbreakpoints">
<title
>Impostare i breakpoint</title>

<para
>(... da scrivere ...) </para>

</sect1
> <!-- settingbreakpoints -->

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1 id ="debuggeroptions">
<title
>Opzioni</title>

<variablelist>
<varlistentry>
<term
>Visualizzare nomi mangled (storpiati)</term>
<listitem>
<indexterm zone="debugger"
><primary
>nomi storpiati</primary
></indexterm>
<indexterm zone="debugger"
><primary
>storpiatura</primary
><secondary
>nome</secondary
></indexterm>

<para
>Nel C++, i nomi delle funzioni negli eseguibili sono detti <quote
>mangled</quote
> (storpiati), &ie; il nome della funzione include le informazioni sul tipo degli argomenti. Questo è necessario per il supporto al sovraccaricamento delle funzioni. L'algoritmo di mangling non è standardizzato e differisce persino tra versioni diverse del compilatore C++ &GNU;. </para>

<para
>Normalmente nella finestra di disassemblaggio vengono visualizzati nomi non mangled, quindi le firme delle funzioni sono simili a come appaiono nel codice sorgente, quindi facilmente leggibili. In alternativa si può decidere di vedere i nomi mangled. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Tentare di impostare i breakpoint al caricamento delle librerie</term>
<listitem>
<indexterm zone="debugger"
><primary
>lazy breakpoint</primary
></indexterm>
<indexterm zone="debugger"
><primary
>Breakpoint</primary
><secondary
>lazy</secondary
></indexterm>

<para
>Il backend del debugger <application
>gdb</application
> non permette di inserire breakpoint all'interno di codice non caricato. Questo potrebbe essere sconveniente in una applicazione altamente modulare, dove spesso il codice viene caricato su richiesta come un plugin (usando la funzione di libc <function
>dlopen(3)</function
>), quindi &tdevelop; ha esteso il proprio supporto per i breakpoint nelle librerie condivise. Se si imposta questa opzione si potranno impostare i breakpoint in librerie che non sono state caricate. Quando <application
>gdb</application
> notificherà che una libreria è stata caricata, &tdevelop; tenterà di impostare i breakpoint sospesi. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Abilitare la barra degli strumenti fluttuante</term>
<listitem>
<indexterm zone="debugger"
><primary
>barra degli strumenti del debugger</primary
></indexterm>
<indexterm zone="debugger"
><primary
>barra degli strumenti</primary
><secondary
>debugger</secondary
></indexterm>

<para
>(... da scrivere ...) </para>
</listitem>
</varlistentry>
</variablelist>

</sect1
> <!-- debuggeroptions -->

</chapter
> <!-- debugger -->