Re: crosstools 0.42 builds arm bootloader executable size > 800 MB

[Duane Ellis <duane at duaneellis dot com>]

Hello,

I would suggest a few other tools.

(1) I presume you know that 'nm' is the host native version of nm, and I 
would suspect is the intel-linux-nm version, not the 
'arm-<whatever>-version your target uses.

Instead of using "size" "nm" "obdjump" - and friends, use the 
"arm-<whatever>-size" program, use the same prefix you use with your 
compiler. Granted: LINUX size sort of works - cause it is ELF and ELF is 
sort of universal... Rather then YMMV - Your Mileage will improve greatly.

(2) Use of arm-<whatever>-objdump with these options will help:

   --section-headers

(3) Look carefully at the output of "objdump" and "nm"

Where is your initialized data segment?
What address does "data' begin at? What address does other things begin at?

A common trick in ROM environments is to COPY the initialized data from 
ROM to RAM as part of the startup code.
Do you know about this? Did you do this? The syntax in the LD script is 
more like:

See this link for details: 
http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_chapter/ld_toc.html#TOC21

  sections {
      .data 0x11110000 :  AT 0x8888000 {
            ....
      }
  }

This tells the LINKER to put DATA at address 0x11110000 - but - in the 
load image - copy/put it some where else. The idea is the startup code 
(crt0.o, or what ever you call yours) will copy it to the correct place 
(ie: From the FLASH chip to the RAM chip) before you get to your version 
of main().  Under OSes that have MMUs - like Linux, this is not normally 
done, because the MMU handles it for you.

If you do this wrong - the linker will ZERO fill like there is no 
tomorrow! (Been there done that)

(4) Another thing it could be is the "elf file alignment" - which I doubt.

ELF is setup so that an operating system can easily MAP the file into 
memory, then play games with the MMU.. If I remember correctly, ARM has 
a default 64K file alignment, this is seperate and distinct from other 
alignments you might use. This is specifically: Any segment must begin 
in the file at an offset that is a direct multiple of ___ bytes. It 
simplifies things for the virtual memory management in  an OS with an MMU.

In particular, the "Elf32_Shdr.sh_offset" value is always a multiple of 
64K, while this nice, and needed for MMU type systems, it is silly in an 
ROM environment. Sadly I don't know the option, or if there is an option 
to tell the BFD lib (and LD) - how to change this alignment. That is to 
say: If you have 2 segments in file (A) and (B). Each with 1 byte, 
within the file they will consume 128K bytes of - you guessed it ZEROS. 
(Or maybe it is 32K file alignment)

I had a problem once, I had a dozen little segments.... times 64K 
alignment... GRRR!!!!!!!!
how many real segments do you have? (ie: not from 'size' - but form 
arm-elf-objdump)
perhaps you have been burned by the same problem I have had.

-Duane.

Jim Tison wrote:
> If Dan's instinct is good (as it often is), I'd suggest that the issue 
> might be found in the linker script -- you might need a special one to 
> solve this problem. I'd start by running the -M (map) option on 'ld' 
> ... verify if you're really getting 800 MB+ of zeros. The map just may 
> point the way to what you'd need to do to the linker script. Assuming 
> we're dealing with ELF, there are ways to get zeroed pages loaded 
> without requiring copies of those pages in the executable. You'll need 
> to find out which control section is holding all those zeroes: 
> hopefully it's distinct from all the others. 'readelf' may also be of 
> help to you (again, assuming ELF format).
>
> Cheers,
> --Jim--
>
> Alex XT.Yan wrote:
> > hi,
> >     I compiled vivi(arm bootloader of Samsung) with crosstools 0.42.
> >     After some Makefile and header hacks like "short-load-bytes" and
> >     "no-fpu", the compilation finishs normally, but the size of the 
> > output
> >     executable (vivi) is 871MB which should be more or less than 70k~!
> >     'ls -l' and 'du -sh' totally make me confused:
> >     $ ls -l vivi
> >     -rwxrwxr-x   1 yanxt   yanxt  871430121  Jul 6 21:53 vivi
> >     $ du -sh vivi
> >     72K     vivi
> >     the needed time for transferring it convices me that 'ls -l' seems
> >     to tell the truth.
> >
> >     Dan suggested that it's mostly zeroes, cos it's asked to be 
> > loaded high     (or that's the default), and it had to pad with zeroes.
> >     Anyone can kindly convince me that please in the attached Makefile?
> >     I can't figure it out yet.
> >     How come this weird thing takes place?
> >     Any advice is appreciated in advance.
> >
> >     Regards,
> >
> >
> >  
> > ------------------------------------------------------------------------
> >
> > Subject:
> > Re: crosstools_0.42 builds arm bootloader executable size > 800 MB
> > From:
> > "Dan Kegel" <dank06@kegel.com>
> > Date:
> > Fri, 6 Jul 2007 10:25:53 -0700
> > To:
> > YanXT <xiaotian.yan@gmail.com>
> >
> > To:
> > YanXT <xiaotian.yan@gmail.com>
> >
> > Delivered-To:
> > xiaotian.yan@gmail.com
> > Received:
> > from gmail-pop.l.google.com [209.85.199.111] by localhost with POP3 
> > (fetchmail-6.3.2) for <YanXT@localhost> (single-drop); Sat, 07 Jul 
> > 2007 10:00:00 +0800 (CST)
> > Received:
> > by 10.114.157.2 with SMTP id f2cs916620wae; Fri, 6 Jul 2007 10:25:53 
> > -0700 (PDT)
> > Received:
> > by 10.115.61.1 with SMTP id o1mr824825wak.1183742753630; Fri, 06 Jul 
> > 2007 10:25:53 -0700 (PDT)
> > Received:
> > by 10.114.171.20 with HTTP; Fri, 6 Jul 2007 10:25:53 -0700 (PDT)
> > Message-ID:
> > <a71bd89a0707061025k1f1b1933v722b8490a8baeac0@mail.gmail.com>
> > Sender:
> > daniel.r.kegel@gmail.com
> > In-Reply-To:
> > <56857a6a0707060903p5c4bbd68kc37fe5d8d6ecaf0d@mail.gmail.com>
> > MIME-Version:
> > 1.0
> > Content-Type:
> > text/plain; charset=ISO-8859-1; format=flowed
> > Content-Transfer-Encoding:
> > 7bit
> > Content-Disposition:
> > inline
> > References:
> > <20070706142215.GA5434@bupt-bcnl.com> 
> > <56857a6a0707060801x7a0a663am72c1da45d7a50f6d@mail.gmail.com> 
> > <a71bd89a0707060824seb90c77h420191502c9d880a@mail.gmail.com> 
> > <56857a6a0707060847i7e5d7efcn98c19b7066a2772e@mail.gmail.com> 
> > <56857a6a0707060903p5c4bbd68kc37fe5d8d6ecaf0d@mail.gmail.com>
> > X-Google-Sender-Auth:
> > 89092c25de65dd75
> >
> >
> > Yeah, sounds like it's mostly zeroes.  I bet you asked
> > for it to be loaded high (or that's the default),
> > and it had to pad with zeroes.
> >
> > I've never dealt with this, you'll have to ask somebody
> > who knows more about linker maps, objcopy, and all that.
> >
> > Try joining the mailing list, maybe it will accept your posts.
> > Or try posting on the binutils mailing list, maybe?
> >
> > On 7/6/07, YanXT <xiaotian.yan@gmail.com> wrote:
> > > size: vivi.HY: File format not recognized
> > > (vivi.HY is shipped with reference arm board)
> > > $size vivi-elf
> > >    text    data     bss     dec     hex filename
> > >   51007    2828   10620   64455    fbc7 vivi-elf
> > > the possibility that there are a lot of zero bytes in it is big:
> > > $tar cjvf vivi-tbz2 vivi
> > > $ls -l vivi-tbz2
> > > -rw-rw-r--  1 yanxt    yanxt    28406  Jul  6 23:52  vivi-tbz2
> > >
> > > it's stripped according to the Makefile:
> > > /usr/local/arm/2.95.3/bin/arm-linux-nm -v -l vivi-elf > vivi.map
> > > /usr/local/arm/2.95.3/bin/arm-linux-objcopy -O binary -S vivi-elf vivi
> > > -R .comment -R .stab -R .stabstr
> >
> >
> > ------------------------------------------------------------------------
> >
> > --
> > For unsubscribe information see http://sourceware.org/lists.html#faq
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq



--
For unsubscribe information see http://sourceware.org/lists.html#faq