Re: [avr-gcc-list] problems with linker

[Steve Joiner]

Ted,

Thanks for the info.  I think I was confused because in an earlier
version of the toolchain, the map file reflected the actual sizes of
the on-chip memories.

This new scheme has left me a little confused as to how the boundaries
of the stack are determined, but I guess I can dig around in the
initialization code to try and figure it out.

Thanks,
Steve Joiner

--- "Theodore A. Roth" <address@hidden> wrote:
> I don't think there's anything wrong. What you are seeing the
> generalization of the linker scripts to handle all the version device
> emulations without the need for a linker script for every device.
> 
> The 0x2000 is devices with up to 8K of flash. The .data section being
> 0xffa0 makes sense too, since adding 0x60 (32 regs + 64 io regs)
> gives you
> 0x10000, or 64k of sram (the entire addressable sram space if
> external
> sram is enabled). As for eeprom, you _could_ address up to 64K of it,
> so
> let the linker think it can.
> 
> If you wish to see how much space your object file is really using,
> use
> 'avr-objdump -h'.
> 
> Ted Roth
> 
> On Wed, 25 Sep 2002, Steve Joiner wrote:
> 
> :)
> :) Well, I got binutils-2.13, rebuilt avr-gcc and avr-libc.
> :) Unfortunately, I still get exactly the same thing -- my sections
> are
> :) the wrong sizes.
> :)
> :) Anyone have any other ideas?
> :)
> :) Thanks,
> :) Steve
> :)
> :) --- Raphael Assenat <address@hidden> wrote:
> :) > Hi, I also had problems building my avr environment using the
> latest
> :) > cvs
> :) > versions of binutils, gcc, and avr-libc, and I followed the same
> :) > instructions
> :) > as you.
> :) >
> :) > I could not compile some of my programs, I got a lot of linker
> errors
> :) > similar
> :) > to this one:
> :) >
> :) >
> :)
>
objs/p1.o(.text+0xb8):/home/raph/0Work/programming/ylib/programs/ATmega163_p1leds/p1.c:228:
> :) >
> :) > relocation truncated to fit: R_AVR_7_PCREL no symbol
> :) > objs/p1.o(.text+0x37c): In function `_p1_expand_data':
> :) >
> :) > I dont understand what exactly was the problem, but when I
> replaced
> :) > binutils
> :) > by the latest release(2.13)(not cvs snapshot) and recompiled gcc
> (3.3
> :) >
> :) > 20020924) as well as avrl-libc (latest cvs), everything went
> well.
> :) >
> :) > I dont know if you're doing something wrong, but maybe you can
> try
> :) > binutils
> :) > 2.13 and see if the problem you've found is fixed.
> :) >
> :) > I hope this helps.
> :) >
> :) > On Tuesday 24 September 2002 04:48 pm, you wrote:
> :) > > Hello,
> :) > >
> :) > > I'm trying to get my avr build environment working.  I've got
> the
> :) > > latest snapshots of binutils and gcc (binutils-020924 and
> :) > > gcc-20020923).  I also grabbed avr-libc from CVS today (9/24).
>  I
> :) > > followed the instructions at
> :) > >
> :) > >
> :) >
> :)
>
http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/insta
> :) > >ll_tools.html
> :) > >
> :) > > and was able to build and install everything without any
> problems.
> :) > > I've got a simple program, foo.c that I'm trying to compile
> for the
> :) > > at90s4433.  I issue the following command:
> :) > >
> :) > > avr-gcc -g -mmcu=at90s4433 -Wl,-Map,foo.map foo.c
> :) > >
> :) > > It builds successfully, but the start of the map file looks
> like
> :) > this:
> :) > >
> :) > > Archive member included because of file (symbol)
> :) > >
> :) > > /usr/local/atmel/lib/gcc-lib/avr/3.3/libgcc.a(_copy_data.o)
> :) > >                               /tmp/ccgWgtvZ.o (__do_copy_data)
> :) > > /usr/local/atmel/lib/gcc-lib/avr/3.3/libgcc.a(_clear_bss.o)
> :) > >                               /tmp/ccgWgtvZ.o (__do_clear_bss)
> :) > >
> :) > > Memory Configuration
> :) > >
> :) > > Name             Origin             Length            
> Attributes
> :) > > text             0x00000000         0x00002000         xr
> :) > > data             0x00800060         0x0000ffa0         rw !x
> :) > > eeprom           0x00810000         0x00010000         rw !x
> :) > > *default*        0x00000000         0xffffffff
> :) > >
> :) > > Linker script and memory map
> :) > >
> :) > > LOAD
> :) > >
> /usr/local/atmel/lib/gcc-lib/avr/3.3/../../../../avr/lib/crts4433.o
> :) > > LOAD /tmp/ccgWgtvZ.o
> :) > > LOAD /usr/local/atmel/lib/gcc-lib/avr/3.3/libgcc.a
> :) > > LOAD
> :) > /usr/local/atmel/lib/gcc-lib/avr/3.3/../../../../avr/lib/libc.a
> :) > > LOAD /usr/local/atmel/lib/gcc-lib/avr/3.3/libgcc.a
> :) > >
> :) > > This seems wrong to me because it is reporting the length of
> the
> :) > text
> :) > > section as 0x2000 and the length of the data section as
> 0xffa0.
> :) > > According to the data sheet, they should be 0x800 and 0xf0,
> :) > > respectively.  The eeprom length looks wrong too.
> :) > >
> :) > > Can anyone tell me what I'm doing wrong here?
> :) > >
> :) > > Thanks,
> :) > > Steve
> :) > >
> :) > >
> :) > >
> :) > >
> :) > >
> :) > > __________________________________________________
> :) > > Do you Yahoo!?
> :) > > New DSL Internet Access from SBC & Yahoo!
> :) > > http://sbc.yahoo.com
> :) > > avr-gcc-list at http://avr1.org
> :)
> :)
> :) __________________________________________________
> :) Yahoo! - We Remember
> :) 9-11: A tribute to the more than 3,000 lives lost
> :) http://dir.remember.yahoo.com/tribute
> :) avr-gcc-list at http://avr1.org
> :)
> 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
avr-gcc-list at http://avr1.org