This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: File Size Problem??
- From: Gary Thomas <gthomas at redhat dot com>
- To: HuangQiang <jameshq at liverpool dot ac dot uk>
- Cc: eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: 11 Dec 2001 14:05:15 -0700
- Subject: RE: [ECOS] File Size Problem??
- References: <KIEBICHBADHFCLGCKOPDOECFCKAA.jameshq@liv.ac.uk>
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
> ...
>