This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about Linking with Application?


On Tue, Dec 11, 2001 at 11:43:54AM -0000, HuangQiang wrote:
> Hi all:
>    I have a question about linking with the application. After building the
> eCOS configuration and get the libtarget.a built. If I compile and link my
> app with the library will all the function inside the library will be linked
> to the final output file?

Nope. All linkers selectively link in what is needed and leave out
what is not. Try it on using. A plain main that just returns is about
a 4K program when statically linked. libc is 2Mbytes. So its obviously
left out what is not needed.

The linker eCos uses is a bit cleverer than a normal linker. Normally
a library is a made of a number of object files. An old style linker
would include the entire object file in the executable if one function
in the object file was needed. This can result in unused functions
linked in. The eCos linker is cleverly. It can pull in single
functions from an object file in the library. This results in much
smaller executables. (The linker sometimes gets is wrong when doing
some complex C++ stuff and throws out used functions!).

In the install/lib directory you will find the libtarget.a file and
extras.o. This extras.o is a linked version of libextras.a. Then the
application is linked extras.o is linked in and the linker is not
allowed to throw out anything from this object file. It contains
things that must be in the application. This includes the startup
code, some of the device drivers, etc. 

When your configuration includes the network stack, it will be
included in your application even when you don't explicitly call
it. There is a function in extras.o which calls the initialization
routine of the stack. Thats enough to pull in most of the stack. Some
of the top level API routines will be missing, but a large part is in,
the basic protocol stack core.

Your bss is so large because the stack uses some big buffers. You can
control the size of these buffers using ecos.ecc, but i think you will
find it hard to get the whole thing in less than 512Kbytes. I've no
personal experience with this, i have 16Mbytes of DRAM!

     Andrew 

 ( It seems to be impossible coz the size of the
> libtarget.a is about 900KB) So what will be linked with my app ( just a
> simple app as Hello World or just a app as: main() {  } nothing inside).  I
> have built the eCOS with TCP/IP support and the physical layer device driver
> for ehernet ( I got the libtarget.a) and I just tried to link it with my
> application( main() { } nothing inside) but I have been told the .bss
> section is out of ram region) I wondered that whether the whole library has
> been linked with my application, even I didn't call any Network support
> function? But the library is about 900KB (it is over the size of the RAM in
> my ARM E7T board 512KB)( template: ARM E7T package: net), so it is
> impossible to link the whole library with the app. If I tried to build an
> other library without the network support its size is 3608KB ( template: ARM
> E7T , default package). but I can build my app with this library and it runs
> ok. so I bet not the whole library will be linked into the app. so what will
> cause the .bss section out of the ram region( I didn't call any network
> support function so why .bss section will be out of region in the one have
> network spport and not in the one without network support? why they are not
> the same?)? Thank you for your help.
> 
> Best regards!
> 
> james
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]