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

[Weddington, Eric]

> -----Original Message-----
> From: Selvaraj, Senthil_Kumar
> Sent: Thursday, February 14, 2013 3:48 AM
> To: address@hidden
> Cc: address@hidden; 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