Newsgroup: it.comp.os.linux.development
Titolo: Gcc e allocazione memoria

Ho notato che il mio gcc alloca piu' memoria di quella che in teoria
dovrebbe per le variabili locali (in particolare i char array); ad esempio:
void foo()
{
    char pippo[12];
}
...
produce un prologo assembler per la funzione foo() di questo tipo:
pushl %ebp
movl %sep, %ebp ...e fin qui tutto OK
subl $24, %esp (!)
dovrebbe, in effetti, sottrarre 12 bytes, invece ne sottrae 24 (0x18).
Ho fatto altre prove, e l'anomalia si ripete, sia con gcc2.96 che con gcc3.
Qualcuno ha riscontrato il mio stesso problema? Qualcuno ha idea da dove
nasca e come risolverlo?
Grazie in anticipo e saluti
Diego

 dovrebbe, in effetti, sottrarre 12 bytes, invece ne sottrae 24 (0x18).
Tiro ad indovinare... Da "man gcc":
     -mcode-align
     -mno-code-align
          Align code to 8-byte boundaries for faster fetching (or
          don't  bother).   Currently turned on by default for C-
          series implementations only.
Se incrementi la dimensione del char[] vedi salti a gruppi di otto?
Se usi l'opzione "-mno-code-align" cambia qualcosa?
Ciao,
-- 
       Roberto Divia`             Love at first sight is one of the greatest
       =============             labor-saving devices the world has ever seen.
Mailbox: C02110                 CERN-European Organization for Nuclear Research
E-mail: 
Robert...@cern.ch
           CH-1211 GENEVE 23, Switzerland

 writes:
DS> Ho notato che il mio gcc alloca piu' memoria di quella che in teoria
DS> dovrebbe per le variabili locali (in particolare i char array); ad esempio:
DS> void foo()
DS> {
DS>     char pippo[12];
DS> }
Che brutta cosa :| ... mica lo usi come buffer di input ? 
DS> produce un prologo assembler per la funzione foo() di questo tipo:
DS> pushl %ebp
DS> movl %sep, %ebp ...e fin qui tutto OK
DS> subl $24, %esp (!)
DS> dovrebbe, in effetti, sottrarre 12 bytes, invece ne sottrae 24 (0x18).
Questioni di allineamento come dice Divia`. A naso usa 16 bit per char...
Non mi pare  che sia l'allineamento del codice a  metterci il naso (lo
stack e` da tutt'altra parte) quanto quello dei dati.
Prova a scrivere un po' di codice extra che faccia un po' di aritmetica
sui puntatori, i.e. 
        *(pippo + 2) = 'A';
e guarda cosa combina il gcc.
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<

 stack e` da tutt'altra parte) quanto quello dei dati.
Purtroppo ho gia' vagliato l'ipotesi dei char a 16bit, ma il bello e' che,
se utilizzo un array di 8 bit, ottengo uno spostamento corretto dello Stack
Pointer (subl $8, %esp); inoltre, riempiendo un po' l'array (ad esempio, con
delle 'A') ed osservando lo stack con gdb (nel caso dell'array da 12 char)
in effetti ho una bella sfilza di 0x41 (12) a partire da ebp-0x18(indirizzo
di pippo[0]), dopodiche' 3 belle dword di spazzatura (i 12 byte rimanenti).
Ho anche gia' osservato l'help, l'info e quant'altro contenuto nel pacchetto
gcc, abilitando e disabilitando vari parametri "sospetti", ma a nulla e'
valso!
Ciao ciao!
Diego

 writes:
DS> Ho anche gia' osservato l'help, l'info e quant'altro contenuto nel
DS> pacchetto   gcc,  abilitando   e   disabilitando  vari   parametri
DS> "sospetti", ma a nulla e' valso!
Hai provato a salire solpra il 12 ?


> Hai provato a salire solpra il 12 ?
char pippo[24] ==> subl $40, %esp
char pippo[64] ==> subl $72, %esp
char pippo[512] ==> subl $520, %esp
char pippo[1024] ==> subl $1032, %esp
char pippo[8192] ==> subl $8200, %esp
...pare che da una certa dimensione in poi sottragga sempre 8 bytes in
piu'...
Diego

> Hai provato a salire solpra il 12 ?
DS> char pippo[24] ==> subl $40, %esp
...
DS> char pippo[8192] ==> subl $8200, %esp
DS> ...pare che da una certa dimensione in poi sottragga sempre 8 bytes in
DS> piu'...
Strano, decisamente strano.
