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

[Antonio Ospite]

On Fri, 23 Apr 2010 09:45:04 -0700
Khem Raj <raj.khem at gmail.com> wrote:

> On Fri, Apr 23, 2010 at 5:28 AM, Antonio Ospite
> <ospite at studenti.unina.it> wrote:
[...]
> > 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.
> >
[...]
> >
> > 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 = .;
> >
> 
> 
> you already have this in stack.S so its not needed. The correct fix would be to
> classify the output segment as NOLOAD explicitly like this
> 
> 	.bss(NOLOAD) : {
> 		__bss_start = .;
> 		/* first the real BSS data */
> 		*(.bss)
> 
> 		/* and next the stack */
> 		. = ALIGN(4);
> 		__stack_start = .;
> 		*(.stack)
> 		__stack_end = .;
> 		__bss_end = .;
> 	}
> 
> you should not need any other changes.
> 

This works in fact. Thanks a lot.

> >> 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
> >>
> 
> The problem is the .stack is
> not a special nobits section like .bss is so when you club is together
> in .bss then
> there is a mismatch and hence the warning.
> 

I see, so when using a recent binutils: being .stack considered progbits
by default, .bss —containing it— is changed to progbits as well if we
don't specify otherwise. While with older binutils .bss was kept nobits
in any case?

Thanks again.

Best wishes,
   Antonio

-- 
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/66d89516/attachment-0002.sig>