{"id":6426,"date":"2011-04-19T17:40:08","date_gmt":"2011-04-19T15:40:08","guid":{"rendered":"http:\/\/www.devapp.it\/wordpress\/?p=6426"},"modified":"2011-04-19T17:40:08","modified_gmt":"2011-04-19T15:40:08","slug":"gdb-gnu-project-debugger-debug-del-linguaggio-assembly","status":"publish","type":"post","link":"https:\/\/www.devapp.it\/wordpress\/gdb-gnu-project-debugger-debug-del-linguaggio-assembly\/","title":{"rendered":"GDB (GNU Project Debugger): Debug del linguaggio Assembly"},"content":{"rendered":"

Assembly? Ma il linguaggio di iOS\/Mac OS non \u00e8 l’Objective-C? Si, certo, ma a volte conviene sfruttare qualcosa che va ancora pi\u00f9 a basso livello per risolvere i nostri problemi, in questi casi parliamo dell’Assembly. In questi anni d’esperienza ho incontrato moltissimi sviluppatori, credo di averne conosciuti pi\u00f9 di 200 (sviluppatori che vantano applicazioni come Delibar, Delicious Library, BBEdit, ecc…), ma pochissimi di loro (forse li riesco a contare sulle dita di una mano) mi hanno detto di aver sfruttato appieno le potenzialit\u00e0 di GDB (GNU Project Debugger). Ecco perch\u00e8 ho deciso di scrivere questo piccolo quickstart, che non sar\u00e0 altro che un punto di partenza nel caso in cui siate interessati ad approfondire la questione, ma veniamo al dunque.<\/p>\n

Quando occorre scendere ad un livello pi\u00f9 basso?<\/h4>\n

Ci sono volte in cui capita di scrivere metodi (magari noiosi) e poi ci si tritrova bloccati per un problema di memoria che non riusciamo a risolvere. Spesso si tratta di errori banali, altre volte di errori un po’ pi\u00f9 complessi, altre volte ancora si \u00e8 talmente sicuri del proprio codice che si arriva a pensare che sia Apple ad aver commesso un errore (mai commettere questo sbaglio :P).<\/p>\n

In ognuno di questi casi, saper sfruttare GDB non \u00e8 un male, anzi, ci si mette un po’ di tempo a prendere confidenza, ma una volta appreso il funzionamento, non si riesce pi\u00f9 a farne a meno.<\/p>\n

Per questa guida sfrutteremo un piccolo esempio pratico, di cui trovate il sorgente disponibile per il download a fondo articolo. Si tratta di un banalissimo programma per iPhone che mostra in una tabella gli URL di 10 technotes presenti sul sito Apple (che consiglio di leggere, male certamente non far\u00e0 :D), prelevati da un semplicissimo array. Al tap su di una cella (row), verr\u00e0 inviato un messaggio all’applicazione di aprire Safari Mobile aprendo l’URL associato. Insomma, un programmino davvero banale e di facile comprensione.<\/p>\n

Vediamo il codice del nostro programma di esempio<\/h4>\n

Iniziamo a vedere il codice del nostro esempio partendo dal file di intestazione (.h) del nostro RootViewController:<\/p>\n


\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-01\"<\/a>
\n<\/center><\/p>\n

Nel file di implementazione (.m) ho quindi istanziato l’array che contiene gli URL che andremo a mostrare e ad aprire direttamente in Safari:<\/p>\n


\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-02\"<\/a>
\n<\/center><\/p>\n

(I pi\u00f9 attenti molto probabilmente si saranno gi\u00e0 accorti dell’errore, ma andiamo avanti ;))<\/p>\n

Mentre i metodi che si occuperanno di avviare Safari sono definiti nel seguente modo:<\/p>\n


\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-03\"<\/a>
\n<\/center><\/p>\n

Alcuni di voi si chiederanno perch\u00e8 ho fatto tutta questa strada per aprire un semplice URL in Safari? La risposta \u00e8 complessa, cercher\u00f2 comunque di non complicare troppo le cose cercando si spegare in modo chiaro: in pratica ho bisogno di diverse iterazioni affinch\u00e8 l’errore si verifichi nel simulatore. Infatti, il simulatore, dispone di tantissima memoria (quella libera nei nostri sistemi) evidentemente molto pi\u00f9 rispetto a quella disponibile normalmente nei nostri iPhone.<\/p>\n

Ok, il codice del nostro piccolo esempio \u00e8 tutto qui. Facciamo partire la nostra applicazione, e noteremo che questa funzioner\u00e0 benissimo… apparentemente!<\/p>\n


\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-04\"<\/a>
\n<\/center><\/p>\n

Se premiamo su una qualsiasi riga della tabella, si aprir\u00e0 Safari senza nessun problema. A questo punto non mi resta che provare a fare lo scroll e siamo a posto: metto il dito, trascino la mia tabella e magicamente… CRASH!<\/p>\n

A primo impatto, penso che non sia possibile, il codice \u00e8 giusto! Riavvio l’applicazione e riprovo! Risultato: stesso comportamento, quando scrollo l’applicazione questa va in crash, ma stavolta \u00e8 avvenuto in un punto diverso rispetto al precedente.. brutto segnale. Mi rimbocco le maniche e mi preparo a cercare di capire dove sta il problema.<\/p>\n


\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-05\"<\/a>
\n<\/center><\/p>\n

Come potete vedere dall’immagine qui sopra, il nostro caro GDB non da nessun errore se non un (fastidiosissimo) EXC_BAD_ACCESS.<\/p>\n

Siccome io so che l’array \u00e8 popolato, e lo capiamo dal fatto che i miei URL sono correttamente stampati nella tabella, provo a cercare di capire cosa non sta effettivamente funzionando e piazzo un bel breakpoint durante il runtime (subito dopo aver fatto partire l’applicazione), nella linea dove prima l’applicazione \u00e8 andata in crash, quindi riprovo ad eseguire uno scroll. Faccio uno “StepIn” cos\u00ec da entrare nel metodo:<\/p>\n

\r\n-(NSString *) getFileNameForIndex:(NSInteger)index\r\n<\/pre>\n
Una volta al suo interno ricevo di nuovo un segnale di errore, ma questa volta si tratta di un SIGABRT:<\/p>\n

\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-06\"<\/a>
\n<\/center><\/p>\n
A questo punto decido quindi di stampare il codice Assembly generato ed ecco il risultato:<\/p>\n

\n\"GDB-GNU-Project-Debugger-Debug-del-linguaggio-Assembly-07\"<\/a>
\n<\/center><\/p>\n
Nelle architetture ARM, le funzioni vengono gestite nel seguente modo:<\/p>\n