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

Hi All,

I open to suggestions on such a feature, but let's talk about it in AVR community first and leave the binutils mailing list out of it until we arrive at a consensus.

Eric

> -----Original Message-----
> From: Georg-Johann Lay 
> Sent: Thursday, February 14, 2013 9:59 AM
> To: Weddington, Eric
> Cc: Selvaraj, Senthil_Kumar; [email protected]; avr-gcc-
> [email protected]; Wunsch, Joerg
> Subject: Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table
> down to last used entry
> 
> 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