avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] linker builds file too big, is it a bug?


From: bob
Subject: Re: [avr-chat] linker builds file too big, is it a bug?
Date: Tue, 15 Feb 2011 12:51:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

On 15/02/11 12:18, Erik Christiansen wrote:
> Hi Bob,
> 
> Thanks for the helpful comment in the source. :-)
> 
> I was briefly slowed down when trying to build it with:
> 
> avr-gcc (GCC) 4.2.2  & avr-ld 2.18.0.20080103
> 
> because my avr-ld is deficient:
> 
> $ make
> avr-gcc -g -Wall -Wno-main --param inline-call-cost=2 -Os -mmcu=attiny13  
> -Wl,-Map,main
> .map -Wl,--section-start=.testparms=0x880 -T tiny13-libc-1.7.0.ld -o main.elf 
> main.o 
> /usr/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: cannot represent machine 
> `avr:25'
> make: *** [main.elf] Error 1
> 
> That would be due to the line:
> 
> OUTPUT_ARCH(avr:25)
> 
> in the linker script, and my binutils 2.18.0 only having:
> 
>   Supported emulations:
>    avr2
>    avr1
>    avr3
>    avr4
>    avr5
>    avr6
> 
> OK, trying "OUTPUT_ARCH(avr:2)", even though I can't immediately
> remember if that's close enough for things to mostly work, just for a
> quick look, I get:
> 
> $ make
> avr-gcc -g -Wall -Wno-main --param inline-call-cost=2 -Os -mmcu=attiny13    
> -c -o main.o main.c
> avr-gcc -g -Wall -Wno-main --param inline-call-cost=2 -Os -mmcu=attiny13  
> -Wl,-Map,main.map -Wl,--section-start=.testparms=0x880 -T 
> tiny13-libc-1.7.0.ld -o main.elf main.o 
> /usr/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: region text is full (main.elf 
> section .text)
> /usr/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: region text is full (main.elf 
> section .text)
> /usr/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: section .init2 [00000000 -> 
> 00000007] overlaps section .text [00000000 -> 00000453]
> /usr/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: main.elf: section .text lma 
> 0x0 overlaps previous sections
> 
> Now that's flagging a memory region overflow, but is it due to some
> .text plus some .data?
> 
> Ooooooooooh Yes! When I comment out your badvar, which _is_ in .data,
> not PROGMEM, all's well. Well well well! :-)
> 
> I'll try making up a test case which replicates your successful error
> messaging, without using any of your IP. With a little luck I'll have
> something tomorrow.
> 
> I don't see anything wrong with the other test case which doesn't
> generate an error, so there's still something to fix in avr-ld, but if
> we can figure what it takes to provide a work-around, that would be very
> nifty.
> 
> Thanks for lending me your working case to distil down. This is
> beginning to be interesting. (I'll delete your files once we have this
> sorted.)
> 
> Until there's more to report;
> 
> Erik
> 
Yes Erik, there is definitely a dissimilarity between these results and
those of Massimiliano.
There was a big revision of the avr arch files sometime in the past. It
would certainly pay to update.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]