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

[Parthasaradhi Nayani]

--- On Sat, 2/21/09, Georg-Johann Lay <address@hidden> wrote:

 
> The trouble might return if .data/.bss will grow and then
> overlap(s)

No sir, I needed 256 bytes buffers two and the other variables may total to 
about 10 or so.

> 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.

If .data and .test are two adjacent sections, I guess there will be no issue 
(well they need not be adjacent for that matter). If my .test section starts at 
a page boundary, it is enough.

> 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. 

Thank you for the clue. I will take care to init the section myself.

>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?


Regards
Nayani