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

[Weddington, Eric]

> -----Original Message-----
> From: Georg-Johann Lay [mailto:address@hidden 
> Sent: Friday, February 20, 2009 4:05 PM
> To: Weddington, Eric
> Cc: address@hidden; avr-gcc-list
> Subject: Re: [avr-gcc-list] introducing a new section in data memory
> 
> Weddington, Eric schrieb:
> 
> 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().


Agreed, on all of the above.
I was just merely testing that the toolchain was not giving some weird error, 
and that, in theory, it could be done.
 
> > 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!

Hmm. If the OP puts it into .bss.test, that may work for the clearing code in 
the startup, but then you may not be able to relocate that section with just a 
command line switch. My guess is that you will have to use a custom linker 
script.
 
> Also nothe that there are some bugs in the patch cited above.

Such as? It works well for most purposes AFIACT.

> I will fix them as soon I will find the time for it.

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

Could you be more specific?