On Fri, 23 Apr 2010 09:45:04 -0700 Khem Raj <raj.k...@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 5:28 AM, Antonio Ospite
> <osp...@studenti.unina.it> wrote:
[...]
> > On Fri, 26 Mar 2010 16:17:24 +0100
> > Antonio Ospite <osp...@studenti.unina.it> wrote:
> >
> >> On Thu, 25 Mar 2010 13:39:00 -0700
> >> Khem Raj <raj.k...@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?
pgpG7MGR7iabR.pgp
Description: PGP signature
