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

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

Re: [avr-gcc-list] introducing a new section in data memory


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] introducing a new section in data memory
Date: Sat, 21 Feb 2009 00:04:49 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Weddington, Eric schrieb:

-----Original Message-----
From: address@hidden [mailto:address@hidden
org] On Behalf Of Parthasaradhi Nayani
Sent: Thursday, February 19, 2009 11:37 AM
To: avr-gcc-list
Subject: [avr-gcc-list] introducing a new section in data memory


Hello all,
I needed to create a buffer of 256 bytes starting at a page boundary (xx00) in the RAM memory (Mega8).
I added this line in the makefile

LDFLAGs = -wl,--section-start=.test=0x800200

and defined a variable in the .C file (shown below)

unsigned char mem3 __attribute__ ((section(".test")));

However variable mem3 is being assigned address 0x60 in the controller???

also if I define another global in next line to mem3 I get error that .data and .bss overlap lma 0xa0?? I am of the opinion that all variable defined with attribute .test will be located in that memory area and all other global variables will be located in their native memory. Perhaps if I ma able locate the .test section properly the overlap error may vanish. Can you correct the problem please? Thank you.


It works for me.

See attached demo. After the build look at the .map file and the disassembly 
file (.dis).

Hi. Without having read all this thread...

The trouble might return if .data/.bss will grow and then overlap(s)
with .test section again. The problem is that you cannot introduce holes in a section, i.e. start with .data, reserve a hole of 0x100 (or put .stuff in it) and then proceed with .data. Therefore, there may be a waste of RAM of up to 0xff bytes.

The only safe way to do this is
-- supplying own linker script that introduces alignment as needed.
-- supplying own linker script that introduces sections .data.lo at
   0x60, .test at 0x100, .data.hi at 0x200. But depending on the
   size of .data, you will have to split .bss instead and explicitely
   say that has to go in the .data fragments. Not nice.
-- or allocate 0x1ff bytes and compute the effective address at runtime.
   But then you must access indirect through a pointer.
-- Maybe it's best to take the space from the top of RAM. Then you will
   waste just 0x60 bytes (or can put some other stuff there), and you
   can use direct addressing if you prefer or need that. Yust init the
   stach pointer to an other value by means of -minit-stack from command
   line or simply by __builtin_alloca (0x160) resp. auto char
   test_buffer[0x160] upon entering main().

Just realize that because your variable is now in the .test section, don't 
expect the toolchain to automatically initialize the variable to zeros in the 
future. It may do that now, but the toolchain will change to not include the 
__do_clear_bss if it detects that there is nothing in the .bss section. The 
variable is now outside the .bss, so there are no guarantees that it will be 
initialized to a known value (zeros) in the startup code.

This can be fixed by renaming the section to .bss.test, as far as you refer to
http://lists.gnu.org/archive/html/avr-gcc-list/2009-01/msg00162.html
But note that the linker assumes one monolithic section, and resp. does
the code in __do_clear_bss resp. __do_copy_data!

Also nothe that there are some bugs in the patch cited above.
I will fix them as soon I will find the time for it.

By the way, what is the specification for the handling of orphans?
Seems as if they are assumed to be adopted by .data?

Georg-Johann





reply via email to

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