huge binary files with objcopy

Question

Im having problems when I define global variables in a basic C program for an ARM9 processor. I'm using EABI GNU compiler and the binary generated from a 12KB elf is 4GB! I assume the issue is with my scatter file but Im having trouble getting my head around it.

I have 256KB of ROM (base address 0xFFFF0000) and 32KBs of RAM (base 0x01000000)

SECTIONS {
  . = 0xFFFF0000;
  .text : {
    * (vectors);
    * (.text);
  }
  .rodata : { *(.rodata) }
  . = 0x01000000;
  sbss = .;
  .data : { *(.data) }
  .bss  : { *(.bss) }
  ebss = .;
  bssSize = ebss - sbss;
}

And my program is as follows:

int a=10;
int main() {
  int b=5;
  b = (a>b)? a : b;  
  return b;
};

If I declare a as a local variable, i.e. there is no .data section then everything works. fine. Any help greatly appreciated.

--16th March 2011--
Can anyone help with this, Im getting nowhere and have read the manuals, forums etc...
My boot, compile command and objcopy commands are pasted below

     .section "vectors"
reset:  b   start
undef:  b   undef
swi:    b   swi
pabt:   b   pabt
dabt:   b   dabt
    nop
irq:    b   irq
fiq:    b   fiq

  .text
start:
        ldr   sp, =0x01006000
        bl    main

stop:   b     stop

arm-none-eabi-gcc -mcpu=arm926ej-s -Wall -nostartfiles -Wall main.c boot.s -o main.elf -T \ scatter_file
arm-none-eabi-objcopy ./main.elf --output-target=binary ./main.bin
arm-none-eabi-objdump ./main.elf --disassemble-all > ./main.dis

Solution 1

I found the problem. The objcopy command will try to create the entire address space described in the linker script, from the lowest address to the highest including everything in between. You can tell it to just generate the ROM code as follows:

objcopy ./main.elf -j ROM --output-target=binary ./main.bin

I also changed the linker script slightly

MEMORY {
  ram(WXAIL) : ORIGIN = 0x01000000, LENGTH = 32K    
  rom(RX)    : ORIGIN = 0xFFFF0000, LENGTH = 32K                    
}

SECTIONS {
  ROM : { 
    *(vectors);
    *(.text);
    *(.rodata);
  } > rom 

  RAM : {
    *(.data); 
    *(.bss);
  } > ram 
}

Solution 2

Adding the (NOLOAD) argument worked for me. E.g.

MEMORY {
  ram(WXAIL) : ORIGIN = 0x01000000, LENGTH = 32K    
  rom(RX)    : ORIGIN = 0xFFFF0000, LENGTH = 32K                    
}

SECTIONS {
  ROM : { 
    *(vectors);
    *(.text);
    *(.rodata);
  } > rom 

  RAM (NOLOAD) : {
    *(.data); 
    *(.bss);
  } > ram 
}

Solution 3

You are creating a file which will starts at address 0x01000000 and will contains at least up to address 0xFFFF0000. No wonder that it is nearly 4GB. What would you like? Try with options -R to remove the data segments if you don't want them (as it is probably the case if you are preparing a ROM initialization file).

Comments

[Amit Sharma]

and how big is the file if you remove line '. = 0x01000000;' ?

[Damn]

Its 364 bytes if I remove the ram address (0x01000000)

[Damn]

I don't understand. I thought the linker script was defining a section starting from 0xFFFF0000 which contains the text, vectors and read only data (i.e. the ROM), so from ffff0000 to the size of all of this. Then another section is defined starting at address 0x01000000 for the data and bss. Whats between these sections is not defined so why is it filling it up? and it only fills it up if I have a global variable. Im trying to use the -R but how do I remove a memory section thats not been defined?

[Damn]

The elf file seems to be ok, it's just the binary thats incorrect.[link](readelf -l main.elf) Elf file type is EXEC (Executable file) Entry point 0xffff0000 There are 2 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x01000000 0x01000000 0x00004 0x00004 RW 0x8000 LOAD 0x010000 0xffff0000 0xffff0000 0x00148 0x00148 R E 0x8000 Section to Segment mapping: Segment Sections... 00 .data 01 .text [\code]

[user1273684]

But isn't the .data segment kinda important too? I can't just throw it away, there is initialized data in there that's lost if you just copy the ROM section.

[ransh]

Any idea about @user1273684 comment ?