crosstools 0.42 builds arm bootloader executable size > 800 MB
Sat Jul 7 15:46:00 GMT 2007
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).
Alex XT.Yan wrote:
> 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.
> Re: crosstools_0.42 builds arm bootloader executable size > 800 MB
> "Dan Kegel" <email@example.com>
> Fri, 6 Jul 2007 10:25:53 -0700
> YanXT <firstname.lastname@example.org>
> YanXT <email@example.com>
> from gmail-pop.l.google.com [18.104.22.168] by localhost with POP3
> (fetchmail-6.3.2) for <YanXT@localhost> (single-drop); Sat, 07 Jul
> 2007 10:00:00 +0800 (CST)
> by 10.114.157.2 with SMTP id f2cs916620wae; Fri, 6 Jul 2007 10:25:53
> -0700 (PDT)
> by 10.115.61.1 with SMTP id o1mr824825wak.1183742753630; Fri, 06 Jul
> 2007 10:25:53 -0700 (PDT)
> by 10.114.171.20 with HTTP; Fri, 6 Jul 2007 10:25:53 -0700 (PDT)
> text/plain; charset=ISO-8859-1; format=flowed
> 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 <firstname.lastname@example.org> wrote:
>> size: vivi: File format not recognized
>> 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
More information about the crossgcc