Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry

[Georg-Johann Lay <avr at gjlay dot de>]

Weddington, Eric wrote:
> 
> Senthil_Kumar Sent:
>> 
>> Hi,
>> 
>> This patch tries to shrink the interrupt vector table by deleting unused 
>> entries at the end of the table as part of linker relaxation.
>> 
>> The motivation for this patch is that, currently, the full interrupt 
>> vector table is being placed in the linked executable, regardless of the 
>> number of interrupts actually used. This increases the size of the 
>> executable for archs (XMEGAs, for example), that have lots of interrupts 
>> (125 interrupts * 4 bytes for XMEGAs) if the user program only uses a few
>> of them.
>> 
>> At a high level, this patch figures out the size of the vector table and 
>> the address of the last entry in the table that has a user defined 
>> handler, and deletes everything in between.
> 
> Hi Senthil,
> 
> We (avr-libc developers) have considered this before and we rejected it for
> safety reasons.
> 
> IIRC, typically, the "unused" vectors will be filled in to jump to a "bad
> interrupt" service routine, which sits in a do-nothing loop forever. What
> this means is that if, for some reason, the end user has accidentally
> enabled other interrupts unintentionally (e.g., by writing certain values to
> the wrong register), then that interrupt would be handled in a safe way: it
> would be stuck in a loop that the user can view in a debugger, letting them
> determine quickly that somehow an interrupt was wrongly enabled. More
> importantly, wrong code is not executed that could harm the rest of the
> embedded system that the AVR devices are in.
> 
> If this "optimization" were put in place, then there is the potential that
> these wrongly-enable interrupts could vector off to some part of the
> application code, start executing it, without ever having a return from
> interrupt (RETI), and could wreak havoc with the rest of the system, and
> also making debugging such a system that much harder.
> 
> I would have to see evidence that these devices, especially the XMEGAs,
> which typically have more code space, are so constrained that such an
> optimization is warranted over the safety of the overall system. IMHO, it
> would be better to focus optimization efforts on improving the AVR backend
> in GCC and code generation, rather than potentially compromising the system
> in this way.
> 
> I'm sorry, but I'm going to have to reject this patch.

IMO it should be in order if the feature is requested per command line option
which is turned off per default.  Thus it's up to the user to decide whether or
not she needs this and prefers reset-style-compromising the system over
some-other-style-compromising the system in case of erroneous source code.

Johann

> 
> We can have further internal discussions about this if you want.
> 
> Eric Weddington Atmel