2012-03-15 4 views
5

Sono un po 'confuso dai risultati che ottengo quando utilizzo la utility della mia toolchain (Yagarto e codesourcery). sta segnalando che sto usando 0 byte nella sezione di dati. vedi sottoPerché la dimensione di arm-none-eabi indica che la sezione .data è 0 anche se sto utilizzando la RAM inizializzata?

$ arm-none-eabi-size.exe rest-server-example.crazy-horse.elf 
    text data  bss  dec  hex filename 
    79364  0 34288 113652 1bbf4 rest-server-example.crazy-horse.elf 

So che il mio codice usa e inizializzazione delle variabili RAM statiche per valori diversi da 0.

abbastanza interessante quando passo lo strumento formato direttamente alcuni dei file oggetto che sono sempre linkato vedo sezione .data stati segnalati

esempio:

text data  bss  dec  hex filename 
    1648  0  20 1668  684 obj_crazy-horse/uip-nd6.o 
    200  12 2652 2864  b30 obj_crazy-horse/uip-packetqueue.o 
    12  0  0  12  c obj_crazy-horse/uip-split.o 
    1816  24  48 1888  760 obj_crazy-horse/usb-core.o 
    284  0  0  284  11c obj_crazy-horse/usb-interrupt.o 
    2064  20  188 2272  8e0 obj_crazy-horse/xmac.o 

Perché il rapporto di file Elf 0 per la sezione .data quando i file oggetto che m ake sta riportando valori diversi da zero?

FYI Sto lavorando su software embedded per un AT91SAM7x256 Micro

edit:

aggiungendo CFLAGS e LDFLAGS

CFLAGS += -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections 

LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map 

Edit # 2: dalla discarica oggetto possiamo vedere chiaramente che la sezione .data ha i dati assegnati ma l'utilità di dimensione non la raccoglie per qualche motivo objdump link

Tutto quello che sto cercando è ottenere un uso esatto della mia RAM. Non sto cercando di capire se una delle mie variabili è stata ottimizzata.

Edit 3: maggiori informazioni da cui risulti che l'utilità taglia non vede qualcosa nella sezione .data

$ arm-none-eabi-size.exe -A -t -x rest-server-example.crazy-horse.elf 
rest-server-example.crazy-horse.elf : 
section    size  addr 
.vectrom    0x34 0x100000 
.text    0x10fc8 0x100038 
.rodata   0x149c 0x111000 
.ARM.extab   0x30 0x11249c 
.ARM.exidx   0xe0 0x1124cc 
.data    0x1028 0x200000 
.bss    0x7bec 0x201028 
.stack    0xa08 0x20f5f8 
.ARM.attributes  0x32  0x0 
.comment    0x11  0x0 
.debug_aranges  0xc68  0x0 
.debug_info  0x2b87e  0x0 
.debug_abbrev  0x960b  0x0 
.debug_line  0x9bcb  0x0 
.debug_frame  0x4918  0x0 
.debug_str   0x831d  0x0 
.debug_loc  0x13fad  0x0 
.debug_ranges  0x620  0x0 
Total    0x7c4c5 
+0

Ho anche controllato il file di mappa e mostra i dati allocati nelle regioni .data della memoria – maguirre

+2

La mia prima ipotesi sarebbe che le sezioni vengano ottimizzate. Stai compilando/linkando con '--gc-sections' e/o' --function-sections'? –

+0

Ho modificato il post originale per maggiore visibilità ma sto usando --function-section. Tuttavia rimuoverlo non cambia nulla per me – maguirre

risposta

2

La mia interpretazione è che lo script del linker crea una singola sezione caricabile, che contiene i valori iniziali di la sezione dati e un pezzo di codice di avvio che copia i dati nella sezione dati non inizializzata.

Questo è necessario se si desidera avere un singolo file immagine che può essere eseguito dalla memoria di sola lettura, poiché non è presente un caricatore ELF che eseguirà quella copia per l'utente.

Normalmente, questo viene fatto solo nella sezione per segmentare il mapping (cioè le sezioni di output sono disposte nello script del linker usando il comando di posizionamento sezione >) piuttosto che mappare la sezione di input due volte, ma ciò è certamente possibile anche .

I numeri di utilizzo sono abbastanza precisi: la dimensione del testo è la quantità di spazio Flash necessaria, la dimensione BSS è la quantità di RAM necessaria. I dati inizializzati vengono conteggiati due volte, una volta per i dati iniziali in Flash e una volta per i dati modificabili nella RAM.

+0

Mi dispiace, Simon. Non sono sicuro di aver capito come questo spieghi i motivi per cui vedo la dimensione 0 nella mia sezione dati. – maguirre

+0

Il file eseguibile non verrà caricato come file ELF, ma convertito in un'immagine binaria non elaborata, per essere scritto nella memoria flash che sarà in sola lettura durante l'esecuzione. Quindi ci sono solo due possibili tipi di sezioni di output: inizializzato/readonly e non inizializzato/read-write. Per avere dati scrivibili inizializzati, si memorizzano i valori iniziali nello spazio inizializzato (insieme al resto di .text/.rodata) e li si copia nello spazio scrivibile per prima cosa dopo l'avvio. Questo viene fatto dal codice di avvio che viene automaticamente collegato per te. –

+0

Penso di capire la tua risposta. Comunque non credo sia la risposta al mio problema. Ho usato countrol sorgente per tornare al mio progetto come originariamente iniziato e devo aver fatto qualcosa perché ad un certo punto la sezione dei dati non era 0 – maguirre

1

La sezione .data ha l'attributo CODE impostato e questo confonde "arm-none-eabi-size". La dimensione della sezione .data viene erroneamente aggiunta alla dimensione totale del testo anziché alla dimensione dei dati.

La mia ipotesi è che si dispone di un codice che viene memorizzato in flash, ma viene copiato su ram in fase di esecuzione come un gestore di interrupt veloce o riprogrammazione flash che deve essere eseguito dalla RAM.Questo imposterà l'attributo CODE per il segmento dati e "size" crede che tutti i dati .data siano testo.

+0

Come puoi dire che è il caso? – maguirre

+0

Da: objdump: Sezioni: 5 .data 00001028 00200000 001125ac 00020000 2 \ * \ * 3 CONTENUTI, ALLOC, CARICO, ** CODICE ** –

Problemi correlati