RE: [ECOS] File Size Problem??

[Gary Thomas <gthomas at redhat dot com>]

On Tue, 2001-12-11 at 13:52, HuangQiang wrote:
> First thank you very much Gray.
> 
> Will the size of binary file = sum of each section of the a.out (image file)
> ??
> 
> Or any relation between binary file size and the sections in the a.out
> (image file)?
> Why the debug appeared in the command output (arm-elf-objdump -h) that I
> havn't include '-g' for creating debug information? and should the debug
> section be count into if calculating the size of the file?
> 

Only the sections marked 'LOAD' will show up in the binary file &/or 
memory.  These would be .fixed_vectors thru .rodata1 in your example.

In this example, the loadable sections are about 0x1800 or 6K, just 
about what you got with "ls -l"

> e.g
> arm-elf-objdump -h
> 
> Sections:
> Idx	Name			Size		VMA		LMA		File off		Algn
> 0	.debug_aranges		00000368	00000000	00000000	000097c4	2**0
> 	CONTENTS,		READONLY,	DEBUGGING
> 1	.debug_pubnames	0000052c	00000000	00000000	00009b2c	2**0
> 	CONTENTS,		READONLY,	DEBUGGING
> 2	.debug_info		00008c4d	00000000	00000000	0000a058	2**0
> 	CONTENTS,		READONLY,	DEBUGGING
> 3	.debug_abbrev		00000c86
> 	xxxxxxxxxxxxxx
> 4	.debug_line		00002c70
> 	xxxxxxxxxxxxxx
> 5	.fixed_vectors		00000140
> 	xxxxxxxxxxxxxx
> 6	.rom_vectors		00000040
> 	xxxxxxxxxxxxxx
> 7	.text			00001650
> 	xxxxxxxxxxxxxx
> 8	.fini			00000000
> 	xxxxxxxxxxxxxx
> 9.	.rodata			00000011
> 	xxxxxxxxxxxxxx
> 10	.rodata1			00000000
> 	xxxxxxxxxxxxxx
> 11	.fixup			00000000
> 	xxxxxxxxxxxxxx
> 12	.gcc_except_table		00000000
> 	xxxxxxxxxxxxxx
> 13	.data			00000120
> 	xxxxxxxxxxxxxx
> 14	.bss			00008180
> 	xxxxxxxxxxxxxx
> 
> 
> 
> ls -l
> 
> b  size 6084
> 
> Any relation ship between those two sizes?
> 
> Thanks a lot!
> 
> best regards!
> 
> james
> 
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gthomas@redhat.com]
> Sent: 2001年12月11日 18:14
> To: HuangQiang
> Cc: eCos Discussion
> Subject: Re: [ECOS] File Size Problem??
> 
> 
> On Tue, 2001-12-11 at 10:35, HuangQiang wrote:
> > Hi all:
> >
> > hello.c ---  int main(void) { return (0);}
> >
> > gcc hello.c
> > size a.exe
> > text	data	bss	dec	hex	filename
> > 1024	1024	12	2060	80c	a.exe
> >
> > arm-elf-gcc xxxxxxx    hello.c xxxxxx  (no debug option -g not listed)
> > arm-elf-size a.out
> > text	data	bss	dec	hex	filename
> > 206540	7484	180644	394668	605ac	a.out
> >
> > Why so much different??? It seems that the arm-elf-gcc output is much
> larger
> > that the gcc output. How can I get the actual size of the app for the arm?
> I
> > convert it to binary by using arm-elf-objcopy -O binary a.out b, I got b
> > 200KB , how come? Is it possible for just for a plain main function? Is
> > there any way to get the size of each section for the binary file?
> 
> For more detailed information, use 'arm-elf-objdump -h'  However, the
> reason for the disparity is that the Linux application only contains
> the code for your program.  The eCos application needs to be stand-alone
> and thus contains the eCos kernel, etc.
> 
> Let's be fair.  On Linux (or any other OS), the 'a.exe' file that you
> quote only has the code+data for "hello.c", whereas your eCos
> application contains that plus the eCos kernel (which may include
> a networking stack and lots of other things).
> 
> If you were to compare apples to apples, you'd need to add in all
> of these things as well:
> 
> [root@hermes parted]# size /boot/vmlinux-2.2.16-22
>    text    data     bss     dec     hex filename
> 1121911  220968  244092 1586971  18371b /boot/vmlinux-2.2.16-22
> [root@hermes parted]# size /lib/libc.so.6
>    text    data     bss     dec     hex filename
> 1259785   18212   16872 1294869  13c215 /lib/libc.so.6
>   ...
>