Visualizzazione dei risultati da 1 a 10 su 11

Hybrid View

  1. #1
    innanzi tutto grazie mille per le risposte

    vorrei solo accertarmi di una cosa: il programma in c che ho mandato in esecuzione conteneva l'unica funzione necessaria per eseguire il programma, cioè il main. Quindi siccome le prime righe del "disassemblaggio" salvavano l'indirizzo di ritorno ed eventuali parametri devo dedurre che il sistema operativo tratta il main come una funzione da inserire nello stack?

    quando quindi viene chiamata una funzione, prima si salvano i parametri, l'sfp( saved frame pointer ) e l'indirizzo di ritorno nel frame pointer e poi si provvede a sottrarre dal top dello stack lo spazio relativo del frame pointer?

    grazie ancora

  2. #2
    Quote Originariamente inviata da maluz1 Visualizza il messaggio
    innanzi tutto grazie mille per le risposte

    vorrei solo accertarmi di una cosa: il programma in c che ho mandato in esecuzione conteneva l'unica funzione necessaria per eseguire il programma, cioè il main. Quindi siccome le prime righe del "disassemblaggio" salvavano l'indirizzo di ritorno ed eventuali parametri devo dedurre che il sistema operativo tratta il main come una funzione da inserire nello stack?
    Ni. Il sistema operativo normalmente fa riferimento ad un entrypoint specificato negli header del file eseguibile, che credo possa omettere il normale preambolo della funzione; il punto è che il tuo main non è il "vero" main, il compilatore specifica automaticamente come entrypoint una funzione che si occupa di inizializzare le strutture della libreria C, eventualmente recuperare e parsare la linea di comando e alla fine chiamare il tuo main come una normale funzione.
    quando quindi viene chiamata una funzione, prima si salvano i parametri, l'sfp( saved frame pointer ) e l'indirizzo di ritorno nel frame pointer e poi si provvede a sottrarre dal top dello stack lo spazio relativo del frame pointer?
    Sui parametri e i registri, dipende dalla calling convention. I parametri possono essere passati in parte in registri e in parte sullo stack, e la responsabilità della pulizia (pop) dei parametri passati sullo stack può essere della procedura chiamante o di quella chiamata (nel primo caso è possibile avere chiamate a funzioni con numero di parametri variabile, nel secondo si ha risparmio in termini di dimensioni dell'eseguibile dato che il codice di pulizia viene scritto una sola volta in fondo alla procedura invece che a tutti i siti di chiamata).
    L'indirizzo di ritorno su x86 viene salvato automaticamente dall'istruzione CALL, e quindi in genere segue immediatamente il push dei parametri.
    Il saved frame pointer (ovvero il valore generato da PUSH esp) può essere necessario o meno; in genere se la procedura non contiene array allocati sullo stack di dimensione non nota non è necessario - il compilatore sa esattamente di quanto ha spostato esp, e può quindi generare la RET di conseguenza.
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.