Project Home
Project Home		 Source Code
Source Code		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Core Development Tools/Discussion/General/Executable code sizes have grown/List of Posts
Forum Topic - Executable code sizes have grown: (8 Items)
   
Update
Ken Schumm
03/12/2008 4:41 PM
post5749
Executable code sizes have grown   
After several updates our executable code sizes seem significantly larger than before. For example, one executable went 
from 45k to 235k, another went from 83k to 237k. This was after installing the latest gdb and Trinity M4 packages 
(haven't downloaded M5 yet).

Is that to be expected?

I haven't examined link maps yet to see where the growth is but in all cases we were using the 4.2.1 compiler.
Aleksandar Ristovski(deleted)
03/12/2008 4:51 PM
post5750
RE: Executable code sizes have grown   
 

> -----Original Message-----
> From: Ken Schumm [mailto:kwschumm@qsolv.com] 
> Sent: Wednesday, March 12, 2008 4:41 PM
> To: general-toolchain
> Subject: Executable code sizes have grown
> 
> After several updates our executable code sizes seem 
> significantly larger than before. For example, one executable 
> went from 45k to 235k, another went from 83k to 237k. This 
> was after installing the latest gdb and Trinity M4 packages 
> (haven't downloaded M5 yet).
> 
> Is that to be expected?


Please try to strip your binaries and then compare the sizes, they should be
close.

---
Aleksandar
Ken Schumm
03/12/2008 5:11 PM
post5751
Re: RE: Executable code sizes have grown   
Stripping helped a small amount but doesn't explain it all.

Binary A pre-stripped was 211k, post-stripped is 167k (still 2x larger than it's 83k size prior to updates)

Binary B pre-stripped was 243k, post-stripped is 168k, (still 2x larger than before).

Which brings up another question. It seems the Windows based eclipse IDE either used to strip automatically or earlier 
binaries were even smaller than mentioned above, what changed?
Thomas Fletcher
03/12/2008 9:51 PM
post5761
Re: RE: Executable code sizes have grown   
On Wed, Mar 12, 2008 at 5:11 PM, Ken Schumm <kwschumm@qsolv.com> wrote:

> Stripping helped a small amount but doesn't explain it all.
>
> Binary A pre-stripped was 211k, post-stripped is 167k (still 2x larger
> than it's 83k size prior to updates)
>
> Binary B pre-stripped was 243k, post-stripped is 168k, (still 2x larger
> than before).
>
> Which brings up another question. It seems the Windows based eclipse IDE
> either used to strip automatically or earlier binaries were even smaller
> than mentioned above, what changed?


It may depend on what functions the executables were using and from what
libraries.  Not all of the
libc functionality is in the .so, some of it is in a static library.  If
content was moved then that would
explain some of the growth.

What does 'size' report (ntox86-size if it is an x86 targetted) on both of
the binaries.  That at least
will provide an idea of where to look for the differences.

Thomas
Ryan Mansfield(deleted)
03/12/2008 9:53 PM
post5762
Re: Executable code sizes have grown   
> After several updates our executable code sizes seem significantly larger than
>  before. For example, one executable went from 45k to 235k, another went from 
> 83k to 237k. This was after installing the latest gdb and Trinity M4 packages 
> (haven't downloaded M5 yet).
> 
> Is that to be expected?

Not if you haven't changed the tools used to generate those binaries. Running  gdb won't modify the binary size in any 
way so it leaves the M4 updates as suspect.

> I haven't examined link maps yet to see where the growth is but in all cases 
> we were using the 4.2.1 compiler.

It sounds as if something that was previously dynamically linked is now being statically linked in. Perhaps one of the 
M4 shared objects wasn't included in the drop and you're now pulling more into your binary. The other is that one of the
 M4 libraries that you were statically linking against has had dependency created against another object in the archive 
so between M4 and what you had before there is more required. 

AFAIK, the IDE only strips binaries on during the debug launch when downloading the binary to the target and it uses a 
temporary copy and does not strip the original binary.

Regards,

Ryan Mansfield
Ken Schumm
03/17/2008 1:25 PM
post5875
Re: Executable code sizes have grown   
I got back to this size issue today. Using one binary as an example, all compiled with 4.2.1

Before Trinity M4, ntoarm-size reports

   text	   data	    bss	    dec	    hex	filename
  27992	    608	  10628	  39228	   993c	gpib_dev_mgr

After Trinity M4, ntoarm-size reports
   text	   data	    bss	    dec	    hex	filename
 157992	   1920	  11324  171236	  29ce4	gpib_dev_mgr

Looking at link maps it seems that a bunch of stuff from libc.a is now being statically linked but I'm not sure why.

In the original small link map the only object statically linked from libc.a is slog.o. This link files shows that the .
so is loaded, then the .a with the lines:
LOAD C:/QNX630/target/qnx6/armle/lib/libc.so
LOAD C:/QNX630/target/qnx6/armle/lib\libc.a

In the new larger executable it seems that all the library code is being statically linked. The link map for this one 
shows:
LOAD C:/QNX630/target/qnx6/armle/lib/libc.a
LOAD C:/QNX630/target/qnx6/armle/lib\libc.a

We're using the IDE on Windoze to build this and the project settings haven't changed.
Ryan Mansfield(deleted)
03/17/2008 1:35 PM
post5876
Re: Executable code sizes have grown   
> I got back to this size issue today. Using one binary as an example, all 
> compiled with 4.2.1
> 
> Before Trinity M4, ntoarm-size reports
> 
>    text	   data	    bss	    dec	    hex	filename
>   27992	    608	  10628	  39228	   993c	gpib_dev_mgr
> 
> After Trinity M4, ntoarm-size reports
>    text	   data	    bss	    dec	    hex	filename
>  157992	   1920	  11324  171236	  29ce4	gpib_dev_mgr
> 
> Looking at link maps it seems that a bunch of stuff from libc.a is now being 
> statically linked but I'm not sure why.
> 
> In the original small link map the only object statically linked from libc.a 
> is slog.o. This link files shows that the .so is loaded, then the .a with the 
> lines:
> LOAD C:/QNX630/target/qnx6/armle/lib/libc.so
> LOAD C:/QNX630/target/qnx6/armle/lib\libc.a

It looks like there was a packaging issue with the Windows M4 drop. libc.so is an empty file and the linker ends up 
linking against libc.a. It should be symlink to libc.so.2 on Linux and Neutrino, and a copy of libc.so.2 on Windows.

Copy C:/QNX630/target/qnx6/armle/lib/libc.so.2 over top of C:/QNX630/target/qnx6/armle/lib/libc.so and you should be 
able to link against the shared library.

Regards,

Ryan Mansfield
Ken Schumm
03/17/2008 1:45 PM
post5877
Re: Executable code sizes have grown   
[...]
 
> It looks like there was a packaging issue with the Windows M4 drop. libc.so is
>  an empty file and the linker ends up linking against libc.a. It should be 
> symlink to libc.so.2 on Linux and Neutrino, and a copy of libc.so.2 on Windows
> .
> 
> Copy C:/QNX630/target/qnx6/armle/lib/libc.so.2 over top of C:/QNX630/target/
> qnx6/armle/lib/libc.so and you should be able to link against the shared 
> library.
> 
> Regards,
> 
> Ryan Mansfield

Ah, *much* better. Thanks!

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems