--- On Sat, 2/21/09, Georg-Johann Lay <a...@gjlay.de> 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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list