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 <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. 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?
pgpe1zF4MN0mz.pgp
Description: PGP signature
_______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel