Von: Peter Bigot Gesendet am: 15 Aug 2010 01:31:02 > I dislike the coupling between binutils and mspgcc that has gcc > decoding section names and changing the flags on the sections it > generates. Especially since with addition of infoa-infod we have six > such sections that would need to be special-cased instead of two > (.noinit is the other). It's cruel to the poor maintainer who's > trying to figure out what's going on, and to any user who wants to > create a similar section and can't see where the magic happens.
Yes, those couplings are nasty. But somethimes there's no way around. > What I propose to do is instead add an attribute like "section" but > titled "nobits" which will change the .section pseudo-op in the > generated assembly code to use @nobits instead of @progbits for > whatever declaration it's attached to. Good idea. Everything that is flagged 'nobits' will consume space in the address range, but produce no code in the binary. Other than the .noinit section, which must be grouped together, so it can be left untouched at startup while the other data sections are copied or initialized, the 'nobits' should be applied to info flash or program flash data space which is just occupied but not filled in the code, eventually leaving the whole info/flash segment untouched by the programmer if there is no other data with 'content'. > This approach should also eliminate the confusion that results if you > use both sections in one application. Currently, the declarations are > independent and therefore overlay each other. Best would be if you simply cannot use both (nobits and progbits) within the same INFO segment. So you'll get a linker warning when initialized data sneaks into a segment which contains unititialized data, causing this segment to be erased during programming. In code flash and ram, this kind of mixing can be necessary, for code flash only if 512 byte aligned, but then, most programmers just do a mass erase of code flash, so the old data is lost anyway. I guess when the concept of ld was made, nobody thought of persistent data inside the program address range. JMGross
