RE: [Patch, avr] Shrink interrupt vector table down to last used entry

["Weddington, Eric" <Eric dot Weddington at atmel dot com>]

> -----Original Message-----
> From: Selvaraj, Senthil_Kumar
> Sent: Thursday, February 14, 2013 3:48 AM
> To: binutils@sourceware.org
> Cc: avr-gcc-list@nongnu.org; Weddington, Eric; Wunsch, Joerg
> Subject: [Patch, avr] Shrink interrupt vector table down to last used
> entry
> 
> 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.

We can have further internal discussions about this if you want.

Eric Weddington
Atmel