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 11:14:19 -0700
- Subject: Re: [ECOS] File Size Problem??
- References: <KIEBICHBADHFCLGCKOPDEECDCKAA.jameshq@liv.ac.uk>
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
...