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; binut...@sourceware.org; avr-gcc- > l...@nongnu.org; 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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
