2013-02-20 18 views
8

Sto eseguendo un programma C di base utilizzando gdb. Ho un punto di rottura all'inizio di main(). Dopo aver eseguito il codice, gdb si interrompe su main() come previsto. Ora, se esamino il registro stack pointer (RSP), sto vedendoRecupero del puntatore dello stack corrente da/proc/pid/stat

0x7fffffffe170: 0x00000000. 

Quando ho recuperare le stesse informazioni utilizzando cat /proc/17232/stat | cut -d" " -f29/proc (dove 17232 è il PID per questo processo), sto vedendo:

140737488347112 (which in hex is: 0x7fffffffdfe8). 

Come mai vediamo un valore diverso del puntatore dello stack corrente da gdb. E anche, perché gdb mostra i contenuti di rsp come NULL (0x00000000)?

Grazie.

risposta

2

stampa RSP registro (su 64b CPU) da /proc

(gdb) info register rsp 
rsp   0x7fffffffe480 0x7fffffffe480 

dà infatti un valore diverso rispetto a quello da /proc

[email protected]:~$ cat /proc/22219/stat | cut -d" " -f29 | perl -e 'print(sprintf("%x\n",<>));' 
7fffffffe338 

dal gdb deve forzare un interruption nel programma all'inizio della principale funzione in ordine prendere il controllo dell'esecuzione e un insieme minimo di dati (indirizzo di ritorno, backup di alcuni registri) viene salvato nello stack. gdb quindi, utilizza il proprio stack per non sovraccaricare il programma uno e effettua le necessarie operazioni di regolazione quando si richiede di visualizzare i registri o di lavorare sui dati dello stack e non mostra la cottura interna gdb. Tuttavia, /proc mostra i dati reali, invariato.

Il "reale" RSP da /proc è in realtà leggermente minore del gdb uno, poiché su x86 CPU stack cresce verso il basso.

Per quanto riguarda il valore null , non è successo durante i miei test

(gdb) x 0x7fffffffe480 
0x7fffffffe480: 0xffffe578 
+0

Grazie per il chiarimento. Cercherò di capire perché la memoria è mostrata come nulla nel mio test. –

Problemi correlati