avr-gcc-list
[Top][All Lists]
Advanced

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

A work-around Re: [avr-gcc-list] strange behaviour of avr-ld, maybe a bu


From: Erik Christiansen
Subject: A work-around Re: [avr-gcc-list] strange behaviour of avr-ld, maybe a bug?
Date: Fri, 18 Feb 2011 02:28:48 +1100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Thu, Feb 17, 2011 at 01:18:40PM +0800, Boyapati, Anitha wrote:
> 
> I think you are right in that the linker should take care of the situation 
> where more than one section loads into a common section/region. I need to 
> give some more thought on it. Will get back if I think otherwise :-)

Anitha, a quick test shows that this linker script addition provides
cumulative overflow detection (using binutils 2.18.0):

   . = ASSERT (_etext + SIZEOF (.data) <= 32K , "Error: .text + .data 
collectively overflow the text region." ) ;

(Or use "ADDR (.text) + SIZEOF (.text)" in place of _etext, if that
looks nicer.)

The "32K" is the text region size in the test case we've used on
avr-chat mail list. Ld syntax doesn't allow a variable in MEMORY region
statements, unfortunately, so we currently seem stuck with a second
magic number. At least, I haven't thought of a solution, here at 2
a.m., beyond using 'INCLUDE <filename>' to bring in a line:

   _text_size = 32K ;

and using the variable in the ASSERT. A line of awk could extract that
from the linker script, but that might be over-finessing a work-around.

I just inserted the ASSERT between .data and .bss output sections in the
linker script.

It seems an easy way to provide detection of cumulative overflow of a
memory region, at least as a work-around.

Erik

-- 
Never worry about theory as long as the machinery does what it's
supposed to do.
                                                  -- Robert A. Heinlein



reply via email to

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