This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]