[oe] gen-blob size with gcc-4.4.2 SOLVED? (was: [PATCH 0/5] Misc updates for EZX bits in OE)

Fri Apr 23 12:28:39 UTC 2010

WARNING:
This was going to be a
  "I didn't know what I was doing but it worked"
kind of post, but then I did some homework and now I think I know a bit
more about what I did :)

The post below is quite lengthy as it contains all the steps I went
through in order to come to some conclusions.

On Fri, 26 Mar 2010 16:17:24 +0100
Antonio Ospite <ospite at studenti.unina.it> wrote:

> On Thu, 25 Mar 2010 13:39:00 -0700
> Khem Raj <raj.khem at gmail.com> wrote:
> 
> > On (25/03/10 18:19), Antonio Ospite wrote:
[...]
> > > Note that although ezx-gen-blob builds fine now, it seems to have issues with
> > > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> > > anyone has a clue please let me know.
> >

Comparing the section sizes for the two binaries:
   text    data     bss     dec     hex filename
  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
  39595  265124       4  304723   4a653 blob-rest-elf32-with-gcc-4.4.2

So something fishing about the data and bss sections. After reading
a bit about what ELF sections are[0,1] I'd guess gcc-4.4.2 might be
forcing initializations for uninitialized data putting it in the
binary image and that makes the object file size grow.

This explanation would also help me to understand more the warning
message:
.../arm-oe-linux-gnueabi/bin/ld:
warning: section `.bss' type changed to PROGBITS

> > I can help you here. If you can give me the two images with symbols and
> > your linking script it uses. Secondly are you using same binutils/ld in
> > both cases ?
> >
>

I also had to learn what a linker script[2] is, it can be used to
define sections properties and object files layout, right?
The one used by blob/gen-blob is here:
http://svn.openezx.org/trunk/src/blob/gen-blob/src/blob/rest-ld-script.in

Now, looking at the bss section, I noted that there is a "nested"
"stack" section, this is different from the other sections, so as a
first naive/blind try I changed that from:
	. = ALIGN(4);
	.bss : {
		__bss_start = .;
		/* first the real BSS data */
		*(.bss) 

		/* and next the stack */
		. = ALIGN(4);
		__stack_start = .;
		*(.stack)
		__stack_end = .;
		__bss_end = .;
	}
to
	/* the BSS section should *always* be the last section */
	. = ALIGN(4);
	.bss : {
		__bss_start = .;
		/* first the real BSS data */
		*(.bss) 
		__bss_end = .;
	}

	/* and next the stack */
	. = ALIGN(4);
	.stack : {
		__stack_start = .;
		*(.stack)
		__stack_end = .;
	}

And the binary sizes is now:
   text    data     bss     dec     hex filename
  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
  39595   20772  227972  288339   46653 blob-rest-elf32-with-gcc-4.4.2

The "strange thing" is that after this blind change from a very rough
guess-work the binary even seemed to work... so I did some more research
to figure out a more "correct" solution.

I found out somewhere on the interwebs that the "nesting" shouldn't be a
problem, and that stack size can be defined directly inside the
linker script, like in [3], so I tried with this change (getting the
actual stack size from src/blob/stack.S):

Index: gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
===================================================================

--- gen-blob-with-gcc-4.4.2.orig/src/blob/rest-ld-script.in
+++ gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
@@ -97,7 +97,8 @@
                /* and next the stack */
                . = ALIGN(4);
                __stack_start = .;
-               *(.stack)
+               /* allocate a 16kB stack */
+               . = . + 16 * 1024;
                __stack_end = .;
                __bss_end = .;


Sizes are now:
   text    data     bss     dec     hex filename
  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
  39595   20772  244356  304723   4a653 blob-rest-elf32-with-gcc-4.4.2

bss size matches, this a good sign, not a coincidence, isnt'it? And
the binary still works. Is that really ok?

[...]
> I am using the very ld the toolchain provides, so I they are
> different, and I noted than the 4.4.2 one gives this warning:
> .../arm-oe-linux-gnueabi/bin/ld:
> warning: section `.bss' type changed to PROGBITS
>

This warning goes away with either the changes above.

So the last patch above would look ok to me, I think I figured out WHAT
was happening, but I don't understand WHY this change is necessary.
Is that the section name ".stack" defined in stack.S is not recognized?
If so, why?

Khem I am now only asking you if you can help me understand why newer
GCCs don't behave in the same way as older ones wrt. this aspect.
Thanks.

> The problem seems to rise during linking indeed, the size difference
> of .o files produced by the two toolchains is ~ 3 KiB overall, it does
> not seem to justify the bump I have after linking to more than 200KiB.
>

After several hours spent on this, but with at least some XP gained :)
Yours truly,
   Antonio

[0]
http://infocenter.arm.com/help/topic/com.arm.doc.dui0101a/DUI0101A_Elf.pdf
[1]
http://www.tortall.net/projects/yasm/manual/html/objfmt-elf-section.html
[2] http://www.math.utah.edu/docs/info/ld_toc.html#SEC4
[3] http://sourceware.org/ml/binutils/2007-11/msg00016.html

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20100423/91c26538/attachment-0002.sig>
