Come funziona esattamente il callstack?

Sto cercando di comprendere più a fondo come funzionano le operazioni di basso livello dei linguaggi di programmazione e soprattutto come interagiscono con il sistema operativo / CPU. Probabilmente ho letto ogni risposta in ogni thread relativo allo stack / heap qui su Stack Overflow, e sono tutti brillanti. Ma c'è ancora una cosa che non ho ancora capito completamente.

Considera questa funzione in pseudo codice che tende ad essere un codice Rust valido ;-)

fn foo() {
    let a = 1;
    let b = 2;
    let c = 3;
    let d = 4;

    // line X

    doSomething(a, b);
    doAnotherThing(c, d);
}

Questo è il modo in cui presumo che lo stack appaia sulla riga X:

Stack

a +-------------+
  | 1           | 
b +-------------+     
  | 2           |  
c +-------------+
  | 3           | 
d +-------------+     
  | 4           | 
  +-------------+ 

Ora, tutto ciò che ho letto su come funziona lo stack è che obbedisce rigorosamente alle regole LIFO (ultimo entrato, primo uscito). Proprio come un tipo di dati stack in .NET, Java o qualsiasi altro linguaggio di programmazione.

Ma se è così, cosa succede dopo la riga X? Perché ovviamente, la prossima cosa di cui abbiamo bisogno è lavorare con ae b, ma ciò significherebbe che il sistema operativo / CPU (?) Deve uscire de cprima tornare a ae b. Ma poi si sparerebbe nel piede, perché ha bisogno ce dnella riga successiva.

Quindi, mi chiedo cosa succede esattamente dietro le quinte?

Un'altra domanda correlata. Considera di passare un riferimento a una delle altre funzioni in questo modo:

fn foo() {
    let a = 1;
    let b = 2;
    let c = 3;
    let d = 4;

    // line X

    doSomething(&a, &b);
    doAnotherThing(c, d);
}

Da come ho capito le cose, ciò significherebbe che i parametri in doSomethingstanno essenzialmente puntando allo stesso indirizzo di memoria come ae bin foo. Ma poi di nuovo questo significa che non ci sarà nessun pop up fino a quando non arriveremo aa eb accadranno.

Questi due casi mi fanno pensare che non ho compreso appieno come funziona esattamente lo stack e come segue rigorosamente le regole LIFO .

Lo stack di chiamate potrebbe anche essere chiamato stack di frame.
Le cose che vengono impilate dopo il principio LIFO non sono le variabili locali ma l'intero stack frame ("chiamate") delle funzioni chiamate . Le variabili locali vengono inserite e inserite insieme a quei frame nel cosiddetto prologo della funzione e nell'epilogo , rispettivamente.

All'interno del frame l'ordine delle variabili è completamente non specificato; I compilatori "riordinano" le posizioni delle variabili locali all'interno di un frame in modo appropriato per ottimizzare il loro allineamento in modo che il processore possa recuperarle il più rapidamente possibile. Il fatto cruciale è che l'offset delle variabili rispetto a un indirizzo fisso è costante per tutta la durata del frame , quindi è sufficiente prendere un indirizzo di ancoraggio, ad esempio l'indirizzo del frame stesso, e lavorare con gli offset di quell'indirizzo per le variabili. Un tale indirizzo di ancoraggio è effettivamente contenuto nella cosiddetta base o frame pointerche è memorizzato nel registro EBP. Gli offset, d'altra parte, sono chiaramente noti in fase di compilazione e sono quindi codificati nel codice macchina.

Questo grafico da Wikipedia mostra come è strutturato il tipico stack di chiamate ¹ :

Aggiungiamo l'offset di una variabile a cui vogliamo accedere all'indirizzo contenuto nel frame pointer e otteniamo l'indirizzo della nostra variabile. Detto così brevemente, il codice vi accede direttamente tramite offset costanti del tempo di compilazione dal puntatore di base; È semplice aritmetica del puntatore.

Esempio

#include <iostream>

int main()
{
    char c = std::cin.get();
    std::cout << c;
}

gcc.godbolt.org ci fornisce

main:
    pushq   %rbp
    movq    %rsp, %rbp
    subq    $16, %rsp

    movl    std::cin, %edi
    call    std::basic_istream<char, std::char_traits<char> >::get()
    movb    %al, -1(%rbp)
    movsbl  -1(%rbp), %eax
    movl    %eax, %esi
    movl    std::cout, %edi
    call    [... the insertion operator for char, long thing... ]

    movl    $0, %eax
    leave
    ret

.. per main. Ho diviso il codice in tre sottosezioni. Il prologo della funzione è costituito dalle prime tre operazioni:

• Il puntatore di base viene inserito nella pila.
• Il puntatore dello stack viene salvato nel puntatore di base
• Il puntatore allo stack viene sottratto per fare spazio alle variabili locali.

Quindi cinviene spostato nel registro EDI ² e getviene chiamato; Il valore restituito è in EAX.

Fin qui tutto bene. Ora accade la cosa interessante:

Il byte di ordine inferiore di EAX, designato dal registro a 8 bit AL, viene preso e memorizzato nel byte subito dopo il puntatore di base : ovvero -1(%rbp), l'offset del puntatore di base è -1. Questo byte è la nostra variabilec . L'offset è negativo perché lo stack cresce verso il basso su x86. L'operazione successiva viene memorizzata cin EAX: EAX viene spostato in ESI, coutviene spostato in EDI e quindi viene chiamato l'operatore di inserimento con coute cessendo gli argomenti.

Finalmente,

• Il valore restituito di mainè memorizzato in EAX: 0. Ciò è dovuto returnall'istruzione implicita . Potresti anche vedere xorl rax raxinvece di movl.
• lasciare e tornare al sito della chiamata. leavesta abbreviando questo epilogo e implicitamente
  • Sostituisce il puntatore dello stack con il puntatore di base e
  • Apre il puntatore di base.

Dopo che questa operazione retè stata eseguita, il frame è stato effettivamente rimosso, sebbene il chiamante debba ancora ripulire gli argomenti poiché stiamo usando la convenzione di chiamata cdecl. Altre convenzioni, ad esempio stdcall, richiedono al chiamato di riordinare, ad esempio passando la quantità di byte a ret.

Omissione del puntatore del fotogramma

È anche possibile non utilizzare offset dal puntatore base / frame ma invece dallo stack pointer (ESB). Ciò rende il registro EBP che altrimenti conterrebbe il valore del puntatore del frame disponibile per un uso arbitrario, ma può rendere impossibile il debug su alcune macchine e sarà implicitamente disattivato per alcune funzioni . È particolarmente utile quando si compila per processori con solo pochi registri, incluso x86.

Questa ottimizzazione è nota come FPO (frame pointer omission) e impostata da -fomit-frame-pointerin GCC e -Oyin Clang; si noti che è implicitamente attivato da ogni livello di ottimizzazione> 0 se e solo se il debugging è ancora possibile, poiché non ha costi a parte questo. Per ulteriori informazioni vedere qui e qui .

¹ Come sottolineato nei commenti, il puntatore del frame è presumibilmente destinato a puntare all'indirizzo dopo l'indirizzo del mittente.

² Notare che i registri che iniziano con R sono le controparti a 64 bit di quelli che iniziano con E. EAX designa i quattro byte di ordine inferiore di RAX. Ho usato i nomi dei registri a 32 bit per chiarezza.

Perché ovviamente, la prossima cosa di cui abbiamo bisogno è lavorare con aeb, ma ciò significherebbe che il sistema operativo / CPU (?) Deve prima uscire d e c per tornare a aeb. Ma poi si sparerebbe nel piede perché ha bisogno di ced nella riga successiva.

In breve:

Non è necessario inserire gli argomenti. Gli argomenti passati dal chiamante fooalla funzione doSomethinge le variabili locali in doSomething possono essere tutti referenziati come un offset dal puntatore di base .
Così,

• Quando viene effettuata una chiamata di funzione, gli argomenti della funzione vengono PUSH in pila. Questi argomenti sono ulteriormente referenziati dal puntatore di base.
• Quando la funzione ritorna al suo chiamante, gli argomenti della funzione restituita vengono inseriti in POP dallo stack utilizzando il metodo LIFO.

In dettaglio:

La regola è che ogni chiamata di funzione produce una creazione di uno stack frame (con il minimo che è l'indirizzo a cui tornare). Quindi, se funcAchiama funcBe funcBchiama funcC, tre stack frame vengono impostati uno sopra l'altro. Quando una funzione ritorna, il suo frame diventa non valido . Una funzione ben comportata agisce solo sul proprio stack frame e non supera quello di un altro. In altre parole, il POPing viene eseguito sullo stack frame in alto (al ritorno dalla funzione).

Lo stack nella tua domanda viene impostato dal chiamante foo. Quando doSomethinge doAnotherThingvengono chiamati, quindi impostano il proprio stack. La figura può aiutarti a capire questo:

Si noti che, per accedere agli argomenti, il corpo della funzione dovrà spostarsi verso il basso (indirizzi superiori) dalla posizione in cui è memorizzato l'indirizzo di ritorno, e per accedere alle variabili locali, il corpo della funzione dovrà attraversare lo stack (indirizzi inferiori ) relativo al luogo in cui è memorizzato l'indirizzo del mittente. In effetti, il tipico codice generato dal compilatore per la funzione farà esattamente questo. Il compilatore dedica un registro chiamato EBP per questo (Base Pointer). Un altro nome per lo stesso è frame pointer. Il compilatore in genere, come prima cosa per il corpo della funzione, inserisce il valore EBP corrente nello stack e imposta l'EBP sull'ESP corrente. Ciò significa che, una volta fatto ciò, in qualsiasi parte del codice della funzione, l'argomento 1 è EBP + 8 di distanza (4 byte per ciascuno degli EBP del chiamante e l'indirizzo di ritorno), l'argomento 2 è EBP + 12 (decimale) di distanza, variabili locali sono EBP-4n di distanza.

.
.
.
[ebp - 4]  (1st local variable)
[ebp]      (old ebp value)
[ebp + 4]  (return address)
[ebp + 8]  (1st argument)
[ebp + 12] (2nd argument)
[ebp + 16] (3rd function argument) 

Dai un'occhiata al seguente codice C per la formazione dello stack frame della funzione:

void MyFunction(int x, int y, int z)
{
     int a, int b, int c;
     ...
}

Quando il chiamante lo chiama

MyFunction(10, 5, 2);  

verrà generato il codice seguente

^
| call _MyFunction  ; Equivalent to: 
|                   ; push eip + 2
|                   ; jmp _MyFunction
| push 2            ; Push first argument  
| push 5            ; Push second argument  
| push 10           ; Push third argument  

e il codice assembly per la funzione sarà (impostato dal chiamato prima di tornare)

^
| _MyFunction:
|  sub esp, 12 ; sizeof(a) + sizeof(b) + sizeof(c)
|  ;x = [ebp + 8], y = [ebp + 12], z = [ebp + 16]
|  ;a = [ebp - 4] = [esp + 8], b = [ebp - 8] = [esp + 4], c = [ebp - 12] =   [esp]
|  mov ebp, esp
|  push ebp
 

Riferimenti:

• Convenzioni per le chiamate di funzione e stack .
• Frame Pointer e variabili locali .
• x86 Disassemblaggio / Funzioni e Stack Frame .

Come altri hanno notato, non è necessario inserire i parametri finché non escono dall'ambito.

Incollerò qualche esempio da "Pointers and Memory" di Nick Parlante. Penso che la situazione sia un po 'più semplice di quanto immaginavi.

Ecco il codice:

void X() 
{
  int a = 1;
  int b = 2;

  // T1
  Y(a);

  // T3
  Y(b);

  // T5
}

void Y(int p) 
{
  int q;
  q = p + 2;
  // T2 (first time through), T4 (second time through)
}

I punti nel tempo T1, T2, etc. sono contrassegnati nel codice e lo stato della memoria in quel momento è mostrato nel disegno:

Processori e linguaggi diversi utilizzano diversi modelli di stack. Due modelli tradizionali sia sull'8x86 che sul 68000 sono chiamati convenzione di chiamata Pascal e convenzione di chiamata C; ogni convenzione viene gestita allo stesso modo in entrambi i processori, ad eccezione dei nomi dei registri. Ciascuno utilizza due registri per gestire lo stack e le variabili associate, chiamati stack pointer (SP o A7) e frame pointer (BP o A6).

Quando si chiama la subroutine utilizzando una delle due convenzioni, tutti i parametri vengono inseriti nello stack prima di chiamare la routine. Il codice della routine quindi inserisce il valore corrente del puntatore del frame nello stack, copia il valore corrente del puntatore dello stack nel puntatore del frame e sottrae dal puntatore dello stack il numero di byte utilizzati dalle variabili locali [se presenti]. Fatto ciò, anche se vengono inseriti dati aggiuntivi nello stack, tutte le variabili locali verranno memorizzate in variabili con uno spostamento negativo costante dal puntatore dello stack e tutti i parametri che sono stati inseriti nello stack dal chiamante potranno essere spostamento positivo costante dal puntatore del fotogramma.

La differenza tra le due convenzioni sta nel modo in cui gestiscono un'uscita dalla subroutine. Nella convenzione C, la funzione di restituzione copia il puntatore al fotogramma nel puntatore allo stack [ripristinandolo al valore che aveva subito dopo che il vecchio puntatore al fotogramma è stato premuto], estrae il vecchio valore del puntatore al fotogramma ed esegue un ritorno. Tutti i parametri che il chiamante aveva inserito nello stack prima della chiamata rimarranno lì. Nella convenzione Pascal, dopo aver estratto il vecchio frame pointer, il processore inserisce l'indirizzo di ritorno della funzione, aggiunge allo stack pointer il numero di byte di parametri spinti dal chiamante, e poi va all'indirizzo di ritorno estratto. Sul 68000 originale era necessario utilizzare una sequenza di 3 istruzioni per rimuovere i parametri del chiamante; i processori 8x86 e tutti i processori 680x0 dopo l'originale includevano un "ret N"

La convenzione Pascal ha il vantaggio di salvare un po 'di codice dal lato del chiamante, poiché il chiamante non deve aggiornare il puntatore allo stack dopo una chiamata a una funzione. Richiede, tuttavia, che la funzione chiamata sappia esattamente quanti byte di parametri il chiamante metterà nello stack. Non riuscire a inserire il numero corretto di parametri nello stack prima di chiamare una funzione che utilizza la convenzione Pascal è quasi garantito per causare un arresto anomalo. Ciò è compensato, tuttavia, dal fatto che un po 'di codice extra all'interno di ciascun metodo chiamato salverà il codice nei punti in cui viene chiamato il metodo. Per questo motivo, la maggior parte delle routine originali della casella degli strumenti Macintosh utilizzava la convenzione di chiamata Pascal.

La convenzione di chiamata C ha il vantaggio di consentire alle routine di accettare un numero variabile di parametri ed essere robusta anche se una routine non utilizza tutti i parametri che vengono passati (il chiamante saprà quanti byte di parametri ha spinto e sarà così in grado di ripulirli). Inoltre, non è necessario eseguire la pulizia dello stack dopo ogni chiamata di funzione. Se una routine chiama quattro funzioni in sequenza, ognuna delle quali utilizza parametri per un valore di quattro byte, può - invece di usare una ADD SP,4chiamata dopo ogni chiamata, usarne una ADD SP,16dopo l'ultima chiamata per ripulire i parametri da tutte e quattro le chiamate.

Oggigiorno le convenzioni di chiamata descritte sono considerate alquanto antiquate. Poiché i compilatori sono diventati più efficienti nell'utilizzo dei registri, è comune che i metodi accettino alcuni parametri nei registri piuttosto che richiedere che tutti i parametri vengano inseriti nello stack; se un metodo può utilizzare i registri per contenere tutti i parametri e le variabili locali, non è necessario utilizzare un frame pointer e quindi non è necessario salvare e ripristinare quello vecchio. Tuttavia, a volte è necessario utilizzare le convenzioni di chiamata precedenti quando si richiamano le librerie collegate per utilizzarle.

Ci sono già alcune ottime risposte qui. Tuttavia, se sei ancora preoccupato per il comportamento LIFO dello stack, pensalo come uno stack di frame, piuttosto che uno stack di variabili. Quello che intendo suggerire è che, sebbene una funzione possa accedere a variabili che non sono in cima allo stack, sta ancora operando solo sull'elemento in cima allo stack: un singolo stack frame.

Ovviamente ci sono delle eccezioni. Le variabili locali dell'intera catena di chiamate sono ancora allocate e disponibili. Ma non sarà possibile accedervi direttamente. Invece, vengono passati per riferimento (o per puntatore, che in realtà è diverso solo semanticamente). In questo caso è possibile accedere a una variabile locale di uno stack frame molto più in basso. Ma anche in questo caso, la funzione attualmente in esecuzione opera ancora solo sui propri dati locali.Sta accedendo a un riferimento memorizzato nel proprio stack frame, che può essere un riferimento a qualcosa nell'heap, nella memoria statica o più in basso nello stack.

Questa è la parte dell'astrazione dello stack che rende le funzioni richiamabili in qualsiasi ordine e consente la ricorsione. Lo stack frame superiore è l'unico oggetto a cui si accede direttamente dal codice. A qualsiasi altra cosa si accede indirettamente (tramite un puntatore che risiede nello stack frame superiore).

Potrebbe essere istruttivo guardare l'assemblaggio del tuo programmino, specialmente se compili senza ottimizzazione. Penso che vedrai che tutto l'accesso alla memoria nella tua funzione avviene attraverso un offset dal puntatore dello stack frame, che è il modo in cui il codice per la funzione verrà scritto dal compilatore. Nel caso di un passaggio per riferimento, si vedranno istruzioni di accesso indiretto alla memoria tramite un puntatore memorizzato a un certo offset dal puntatore dello stack frame.

Lo stack di chiamate non è effettivamente una struttura di dati dello stack. Dietro le quinte, i computer che usiamo sono implementazioni dell'architettura della macchina ad accesso casuale. Quindi, è possibile accedere direttamente a aeb.

Dietro le quinte, la macchina:

• ottenere "a" equivale a leggere il valore del quarto elemento sotto lo stack top.
• ottenere "b" equivale a leggere il valore del terzo elemento sotto lo stack top.

http://en.wikipedia.org/wiki/Random-access_machine

Ecco un diagramma che ho creato per lo stack di chiamate di C. È più preciso e contemporaneo rispetto alle versioni di immagini di Google

E corrispondente alla struttura esatta del diagramma sopra, ecco un debug di notepad.exe x64 su Windows 7.

Gli indirizzi bassi e gli indirizzi alti vengono scambiati in modo che lo stack salga verso l'alto in questo diagramma. Il rosso indica la cornice esattamente come nel primo diagramma (che utilizzava rosso e nero, ma ora il nero è stato riproposto); il nero è lo spazio domestico; il blu è l'indirizzo di ritorno, che è un offset nella funzione chiamante dell'istruzione dopo la chiamata; l'arancione è l'allineamento e il rosa è il punto in cui il puntatore dell'istruzione punta subito dopo la chiamata e prima della prima istruzione. Il valore homespace + return è il frame più piccolo consentito su Windows e poiché l'allineamento rsp a 16 byte all'inizio della funzione chiamata deve essere mantenuto, questo include sempre anche un allineamento a 8 byte.BaseThreadInitThunk e così via.

I riquadri funzione rossi delineano ciò che la funzione chiamata "possiede" logicamente + legge / modifica (può modificare un parametro passato nello stack che era troppo grande per essere passato in un registro su -Ofast). Le linee verdi delimitano lo spazio che la funzione si alloca dall'inizio alla fine della funzione.