[uClinux-dev] 5208EVB m68k-uclinux/elf-gcc code size difference
Martin Voss
Martin.Voss at brv.se
Tue Aug 14 12:37:57 EDT 2007
I have digged further into my issue with different object file sizes
depending if I compile with m68k-uclinux on SBCTools on a PC or m68k-elf
on a Red Hat 9 machine. Consider the following simple test program which
consists of two source files:
foo.c:
int bigarray[10000];
void reset_array(void)
{
int i;
for(i = 0; i < 10000; i++)
bigarray[i] = 0;
}
main.c:
#include <stdio.h>
void reset_array(void);
extern int bigarray[10000];
int main(int argc, char **argv)
{
int i;
reset_array();
for(i = 0; i < 10000; i++)
printf("%d", bigarray[i]);
return(0);
}
When I compile on the PC using SBCTools (as shipped with EVB5208 using
m68k-uclinux-gcc):
foo.o is 900 bytes
main.o is 1148 bytes
Executable file is 19940 bytes
An "m68k-uclinux-objdump -x" on each file gives the following:
foo.o: file format elf32-m68k
foo.o
architecture: m68k, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000038 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 0000006c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 0000006c 2**2
ALLOC
3 .comment 000000a6 00000000 00000000 0000006c 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 foo.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l .text 00000000 gcc2_compiled.
00000000 l d .comment 00000000
00000000 g F .text 00000038 reset_array
00009c40 O *COM* 00000002 bigarray
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000001a R_68K_GOT16O bigarray
and on main.o:
main.o: file format elf32-m68k
main.o
architecture: m68k, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000062 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000098 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000098 2**2
ALLOC
3 .rodata 00000003 00000000 00000000 00000098 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 000000a6 00000000 00000000 0000009b 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 main.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l .text 00000000 gcc2_compiled.
00000000 l d .rodata 00000000
00000000 l .rodata 00000000 .LC0
00000000 l d .comment 00000000
00000000 *UND* 00000000 __main
00000000 g F .text 00000062 main
00000000 *UND* 00000000 reset_array
00000000 *UND* 00000000 bigarray
00000000 *UND* 00000000 printf
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000006 R_68K_PC32 __main+0xfffffffa
00000010 R_68K_PC32 reset_array+0xfffffffa
0000002c R_68K_GOT16O bigarray
00000040 R_68K_GOT16O .LC0
00000046 R_68K_PC32 printf+0xfffffffa
If I the compile the same program (installed in the user dir) on a
RedHat 9 machine:
foo.o is 40868 bytes
main.o is 1100 bytes
Executable file is 59160 bytes
An objdump on the .o files gives:
foo.o: file format elf32-m68k
foo.o
architecture: m68k, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
privata flaggor = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000018 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00009c40 00000000 00000000 0000004c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00009c8c 2**2
ALLOC
3 .comment 000000a6 00000000 00000000 00009c8c 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 foo.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l .text 00000000 gcc2_compiled.
00000000 l d .comment 00000000
00000000 g F .text 00000018 reset_array
00000000 g O .data 00009c40 bigarray
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000004 R_68K_GOT16O bigarray
and the main.o:
main.o: file format elf32-m68k
main.o
architecture: m68k, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
privata flaggor = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000034 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000068 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000068 2**2
ALLOC
3 .rodata 00000003 00000000 00000000 00000068 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 000000a6 00000000 00000000 0000006b 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 main.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l .text 00000000 gcc2_compiled.
00000000 l d .rodata 00000000
00000000 l .rodata 00000000 .LC0
00000000 l d .comment 00000000
00000000 *UND* 00000000 __main
00000000 g F .text 00000034 main
00000000 *UND* 00000000 reset_array
00000000 *UND* 00000000 bigarray
00000000 *UND* 00000000 printf
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000004 R_68K_GOT16O __main
0000000a R_68K_GOT16O reset_array
00000012 R_68K_GOT16O bigarray
0000001a R_68K_GOT16O .LC0
0000001e R_68K_GOT16O printf
Obviously the large array is placed in the data section and initialized
with zeroes. This explains the larger object/exe files.
If using objdump and looking at the comments section the gcc version is:
GCC: (GNU) 2.95.3 20010315 (release)(ColdFire patches - 20010318 from
http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from
http://www.snapgear.com/).
on both the PC and the RH9 machine.
I'm a bit confused why the m68k-elf version uses the data section for an
uninitialized array? Should not the bss section be used for this? Or is
something broken in the m68k-uclinux toolchain I use?
If anyone can shed some light on this I would definitely sleep better.
:)
Best regards,
Martin Voss
More information about the uClinux-dev
mailing list