On Fri, Apr 23, 2010 at 5:28 AM, Antonio Ospite <osp...@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 <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 = .; >
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? >