[oe] gen-blob size with gcc-4.4.2 SOLVED? (was: [PATCH 0/5] Misc updates for EZX bits in OE)
Khem Raj
raj.khem at gmail.com
Fri Apr 23 16:45:04 UTC 2010
On Fri, Apr 23, 2010 at 5:28 AM, Antonio Ospite
<ospite at studenti.unina.it> wrote:
> 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 = .;
>
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.
>
> 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
>>
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.
>
> 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?
>
More information about the Openembedded-devel
mailing list