That's an interesting observation. I never encountered this as I never had an interrupt function on its own in a separate compilation unit. Yes, there are no references, even the entry for the vector table (which is referenceing the interrupt routine, of course) is local and therefore does not force the linker to link the file. Perhaps if one would generate weak references to the dummy ISR for all interrupt vectors, the linker would detect that there is something overriding these weak references an dlink. But only if the vecto table with these weak references is in a separate file other than the dummy ISR, or lese the references woul dbe resolved locally and again no external reference would be created.
Anyway, I usually put the ISRs together with the related function. The timer ISR together with the timer init function, the UART ISRs together with the code stuffing data into the ringbuffer etc. This way, if none of the UART functions is used, none of the code is linked, but if, all of the code gets linked. JMGross ----- Ursprüngliche Nachricht ----- Von: Anthony Asterisk An: [email protected] Gesendet am: 17 Mrz 2010 21:08:26 Betreff: Re: [Mspgcc-users] mspgcc4 usci.h error in definition of UCBxCTL0/1 Will these patches being going into GCC cvs? BTW, other than these minor header file issues I haven't had any major issues with mspgcc4 on msp430F5437. One small thing that snagged me...I had my interrupt routines in a file by themselves. Since the interrupts were not called from any other code that did not get linked to the final object file. Only by adding a dummy routine that I called from main was I able to get the interrupts to be linked in. I'm guessing this is actually normal gcc behavior and not mspgcc4 specific, but just wanted to mention it.
