> -----Original Message----- > From: Georg-Johann Lay [mailto:[email protected]] > Sent: Friday, February 20, 2009 4:05 PM > To: Weddington, Eric > Cc: [email protected]; 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? _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
