Problem with objcopy

[Leon Pollak]

Dear Tim.

You are absolutely right - my script on error puts bss section before data.

Many thanks!!!



On Thursday June 25 2009, Tim Cussins wrote:
> Hi Leon,
>
> On Thu, 2009-06-25 at 14:26 +0300, Leon Pollak wrote:
> > Hello, all.
> >
> >
> >
> > Recently I made a small change in the following code:
> > class cFoo {
> > protected:
> > uchar DataIn[MAX_DATA_LEN], DataOut[MAX_DATA_LEN];
> > ..............
> > };
> >
> >
> >
> >
> > I changed MAX_DATA_LEN from 1000 to 300000.
> >
> >
> >
> >
> > This resulted in 300000 growth of the BIN file which I produce by
> > command:
> > powerpc-rtems-objcopy -j .text -j .data -O binary app.elf app.bin
>
> surely you'd see 2x that growth - you've got 2 member variables that
> depend on MAX_DATA_LEN...
>
> > Looking into the map file I see that the real addition of 300000 bytes
> > resides in the .bss section, which seems to me correct.
> > So, why the size of binary file depends on .bss section size?!?!
>
> without seeing your linker script, perhaps section .bss is listed in
> front of .data, and it's pushing up the LMA of .data - this would appear
> as a giant section of zeros in your binary image, and the binary size
> increase you're talking about...
>
> > I tried to play with -j and -R parameters, but all imaginable
> > combinations gave nothing - the output file size was exactly the same.
>
> above explanation could account for this. AFAIK objcopy uses (quite
> rightly) the LMA to position sections in the binary output.
>
> > Many thanks ahead for any help.
> > --
> > Leon
>
> Hope this provides some food for thought...
> Tim


-- 
Leon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090625/acd89ded/attachment-0001.html>