|
 |
Il Processore e il Debugger |
DEBUG 6/22
[34 di 60] |
|
 |
|
Aggiornato
24 settembre 2003 e 17 febbraio 2005 |
 |
|
Comando D - Analizza il contenuto della memoria [prima
parte] |
|
 | Il nostro Debug è una vera bomba... Evitiamo,
per ora, di assumere files da controllare: già così, da solo, questa
utility mostra la sua assoluta versatilità. |
 |
Se
vuoi trarre il massimo profitto dalle pagine di questo paragrafo ti
conviene aprire una shell Dos (cliccando sulla corrispondente
icona del menu d'Avvio) e provare in diretta le cose
che descriveremo: digita subito DEBUG e, quando appare il trattino,
a sinistra, digita i comandi che ti suggerirò, di volta in volta.
Diventerai ben presto autonomo e sicuro e ti verrà voglia di
provare da solo... |
| Cominciamo con il comando D,
DUMP; già il nome merita una pausa di
riflessione:
 | il sostantivo dump
significa letteralmente bidone della spazzatura,
posto sudicio, o più elegantemente cestino
dei rifiuti; |
| il verbo dump
significa invece rovesciare |
|
| La brillante verve anglosassone
ha colpito ancora... quando si richiede un dump qualcuno ci rovescia
il cestino dei rifiuti sulla scrivania...; proprio quello che
facciamo noi quando, disperati, ci accorgiamo di avere cestinato, per
errore, un documento a cui tenevamo. Il comando D
vuota sul video una bella fetta di memoria, mostrandone tutti i dettagli
possibili. |
| Aldilà della metafora questo comando è
veramente potente, sebbene lo si possa apprezzare solo quando si ha
effettivamente qualcosa da cercare; premendo la lettera D,
senza nessuna altra specifica, appare a video questa schermata: |
 |
Se fai click sull'icona a
sinistra si apre l'Ambiente Assembly
e puoi
provare DEBUG
on-line.
Scegli
il pulsante di opzione "Aprire il file" o "Esegui
l'applicazione"
e conferma
con
OK.
NB: alcuni gestori di protezione (per esempio SP2 di WinXP) non ti consentono questa operazione:
in questo caso scrivi c:\arch-lab\bin\sys\assembler.pif direttamente nel campo indirizzo del Browser |
 |
| NB: la prima cosa che
salta agli occhi è la naturalezza con cui DEBUG
tratta le informazioni: poiché è uno strumento dedicato all'analisi del
processore (i suoi
registri) e della
memoria ogni numero da esso
presentato sul monitor va inteso espresso
nella lingua del processore cioè esadecimale. |
| Si tratta di uno strumento dedicato per cui, in questo
ambiente, la presenza della 'H'
che ci siamo educati a mettere dopo ciascun numero esadecimale
è data per scontata. |
| Naturalmente la regola vale anche quando saremo chiamati a
dare informazioni a
DEBUG, per fissare un
indirizzo o per predisporre il valore di
un registro o di una locazione di memoria... I numeri (esadecimali) digitati
dovranno essere forniti senza la 'H'
finale! |
 |
E' importante ricordare fin d'ora che i numeri
esadecimali si possono trattare senza la "H" posteriore
solo quando abbiamo a che fare con
DEBUG; se è vero che esso non capirebbe (segnalando
errore...) comandi del tipo D 0100H
è altrettanto vero che l'assemblatore farebbe altrettanto se invece
dimenticassimo di metterla . Questo concetto è ripreso e spiegato
in
questa pagina. |
| Detto questo, analizziamo la videata ottenuta; sono
8 righe così strutturate:
| il campo di sinistra (in verde) mostra l'indirizzo segmentato della prima locazione di memoria che andremo ad
ispezionare: il puntatore è inteso espresso in esadecimale. |
| il campo centrale (in celeste) elenca il
contenuto delle 16 locazioni consecutive, a partire da quella
indirizzata dal primo campo, espresso in esadecimale. |
| il campo di sinistra (in giallo) cerca di
tradurre in forma Ascii il contenuto delle medesime
locazioni. |
|
| Le 7 righe successive hanno la medesima
struttura e descrivono altre 16 locazioni ciascuna, per un totale di
128
(un ottavo di kBytes). |
| Valutiamo in modo critico le informazioni di
questa immagine:
| l'indirizzo di segmento è, per tutti i
puntatori, sempre lo stesso (nell'esempio 0DE0):
il suo valore dipende esclusivamente da quello della prima zona di ram
libera al momento del caricamento del debugger in memoria; questo ultimo
riserva ai nostri esperimenti un intero segmento che comincia proprio da
0DE0:0000. |
| l'indirizzo di
offset iniziale è 0100:
il suo valore risente del fatto che Debug ha riservato per se stesso le
prime 256 locazioni, per ospitare, nella logica dei programmi gestiti
dal Dos, il proprio PSP). |
| la sequenza dei numeri seguenti è
esattamente la traduzione esadecimale di quello che debug ha
effettivamente trovato: il loro valore è assolutamente imprevedibile e
può essere cambiato in ogni momento, senza provocare alcun danno, come
vedremo nelle prossime pagine. |
| la zona gialla dei caratteri
Ascii è illeggibile,
tanto più quanto maggiore è la casualità dell'area di memoria
analizzata; tutti i bytes che corrispondono a caratteri
Ascii stampabili sono
mostrati per quello che sono, mentre tutti gli altri (da
00H a 1FH, caratteri
di controllo, e da
80H a FFH, caratteri
ascii estesi) sono
visualizzati con un punto. |
|
| Per motivi di chiarezza la sequenza dei
16 bytes di ciascuna riga è divisa in 2 da un
trattino. |
| Se il comando D
viene dato di nuovo, viene rovesciata a
video la successiva "cestinata" di
128 bytes, e così ad oltranza. |
| Se si desidera tornare all'inizio o se si
vuole analizzare un'altra parte della memoria basta specificare l'indirizzo
subito dopo la lettera D, ma di questo
parleremo nella prossima pagina. |
©
2001-2010 - Studio Tecnico
ing. Giorgio OBER
Tutti i diritti sono riservati
|
