On 22/09/10 17:49, Erik Christiansen wrote: >> I just removed ,init1 & .init2 from the linker script and replaced it >> with my own code in a new section. > > That's not a really good idea. They're standard sections, the compiler > wants to put the default initialisation code in there. And you can use > that code as is. If empty, the sections are simply omitted. (You have > seen that crttn13.o only has two of the ten.) > >> Only small thing is, that if my code: >> does not actually exist (e.g. comment it out, the linker does not throw >> any kind of error (not even an incomprehensible one!!), the code is, of >> course, missing from the output. > > It is not an error for an input section to be empty. You probaly have > more than half of .init0 - .init9 empty. What you've done is quite > normal, except that it is much easier to place it in one of the existing > .init sections. e.g. If you have a hardware init for a peripheral chip, > and one for some code which uses it, you might put the former in .init3 > and the latter in .init4, to make sure the execute in the right order. > (Can't think of a better example at this hour.)
Hi Erik, I need to remove the code from .init2. If I make an init2 section, the compiler includes my code but also adds the default stack pointer setting (which I cannot have, for resaons explained). So, either I rewrite crttn13.o which means recompiling the toolchain to be non-standard (for all projects), as it is itself compiled during the install process, or I make a linker script which is then specific only for those projects that require it. Setting the stack in software is not an option if I want to achieve my hardware-independant goal. (OK - not quite true, but the way I want to go :-) ). I see that you are right, it cannot be an error for no code to be written - I could just as easly omit hw initialisation im my main() and it wouldn't squawk - it just looks wrong in a c source to have a function (although it isn't a function really) that you can comment out and no one cares - wrong thinking on my part :-( Again, many thanks, Robert _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
