[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] Variable __data_end variable not passed through to li
RE: [avr-gcc-list] Variable __data_end variable not passed through to linker for use in __heap_start?
Tue, 11 Apr 2006 10:10:58 +1000
I just tried this script file, by setting the LDFLAGS variable in the
LDFLAGS = -Wl,-Tlinkscript.x
, and get the following errors:
"address 0x800550 of main.elf section .data is not within region xdata"
"section .bss [00800060 -> 008008aa] overlaps section .data [00800100 ->
I tried a make clean && make, but it doesn't seem to make any
difference. It appears that something in the .data section is being
linked into the internal RAM, then the linker doesn't like it because it
appears outside that memory space. Any clues to fix this? Could it be
something in the avr-libc library that needs to be re-compiled/linked?
I note that right at the top of the generated map file the following
"Address of section .data set to 0x800100"
However the linker script doesn't seem to refer to this address at all.
I have managed to fix it with some amount of dodginess: using the
original linker script (avr5.x), I added on the linker command line a
force of the .data section to start at the xram start (0x808000). I also
added a __heap_start PROVIDE driective to the linker script, to force
the export of the heap start value into the linked code.
In summary, to make it work, I did the following:
* Added PROVIDE (__heap_start = .) ; directive just after the original
__data_end directive in avr5.x;
LDFLAGS += -Wl,--section-start,.bss=0x800100 \
Directives to force the location of .bss and .data.
Matthew van de Werken - Electronics Engineer
CSIRO E&M - Rock Mass Characterisation - 1 Technology Court - Pullenvale
p: (07) 3327 4142 * f: (07) 3327 4455 * e: address@hidden
"We do not inherit the earth from our ancestors, we borrow it from our
-- Native American Proverb
> -----Original Message-----
> From: Ned Konz [mailto:address@hidden
> Sent: Tuesday, 11 April 2006 2:05 AM
> To: address@hidden
> Cc: Van De Werken, Matt (E&M, QCAT)
> Subject: Re: [avr-gcc-list] Variable __data_end variable not
> passed through to linker for use in __heap_start?
> On Apr 9, 2006, at 8:41 PM, <address@hidden>
> <address@hidden> wrote:
> > Hi all:
> > I am running winavr 2006*, on an atmega128 with 32k of XRAM
> mapped to
> > 0x8000->0xFFFF. I would like the .bss memory section to be
> > allocated by
> > the linker in the internal RAM, while I'd like the .data section
> > and the
> > __malloc_heap_start to both be in XRAM. .bss being in IRAM is not
> > really
> > negotiable, and I'd much prefer .data to live in XRAM, due to the
> > larger
> > size of that section.
> > Unfortunately, the makefile I'm using doesn't seem to want
> to allocate
> > the __malloc_heap_start variable to the __data_end.
> > I've tried adding the following options, with no success:
> > LDFLAGS += -Wl,--section-start,.bss=0x800100 \
> > -Wl,--section-start,.data=0x808000) \
> > -Wl,--defsym,__heap_start=__data_end \
> > -Wl,--defsym,__heap_end=0x80FFFF \
> > The problem I have is that any memory I allocate with malloc ends
> > up in
> > the internal RAM, straight after .bss.
> > However, if I hard-code the __heap_start variable (to, say,
> > 0x809000), I
> > have no problems - the malloc'ed memory is allocated in XRAM. This
> > is a
> > less than ideal situation, obviously, however I don't seem to be
> > able to
> > pass through the __data_end variable into the __heap_start (and
> > onwards
> > to __malloc_heap_start).
> > Anyone run into this before, and/or any suggestions??
> Sure: why not just define a custom linker script?
> It's quicker than all that command-line stuff anyway.
> Anyhow, seems like someone was complaining that the
> command-line args
> didn't work anyhow.
> Try the attached.
> It results in:
> .data 0x00808000 0x6
> 0x00808000 PROVIDE (__data_start, .)
> 0x00808002 __malloc_heap_start
> 0x00808000 __malloc_heap_end
> 0x00808004 __malloc_margin
> 0x00808006 _edata = .
> 0x00808006 PROVIDE (__data_end, .)
> 0x00808006 PROVIDE (__heap_start, .)
> .bss 0x00800060 0x4
> 0x00800060 PROVIDE (__bss_start, .)
> 0x0080ffff __heap_end = 0x80ffff
> Ned Konz