On Fri, Feb 15, 2013 at 08:31:42AM +0100, Georg-Johann Lay wrote: > Senthil Kumar Selvaraj wrote: > > > >Like the others said, the patch does not change the default behavior > >for unhandled interrupts - they still branch to __bad_interrupt. The > >user would have to explicitly use the --shrink-ivt option to change > >that - at which point, I guess he should be knowing what he's doing. > > If the feature is off per default, that should be enough to make it > a "safe" feature. User will know what options they are activating. > > What I don't like is the "--shrink-ivt", I'd rather prefer something > less cryptic like "--shrink-vectors" or "--optimize-vectors" or > similar.
Yeah, ivt is cryptic, but my reasoning was "vector" could be ambiguous - vector processors / instruction optimization and such. I guess it doesn't make much sense for AVR binutils though, so whatever name the community finds meaningful is ok. > > One technical question: > > Does this really need binutils changes, or could it be achieved by > linker script improvements, e.g. start .text after the last .vector? > > Currently the size of .vectors is forced by crt.o, but maybe there > are other way to do it? > I couldn't think of any. Normally, -ffunction-sections and discarding unused input sections makes the linker exclude unused code, but that obviously won't work for the vector table and interrupt handlers, as there are no explicit references/callers. I don't know if all the logic can be expressed in a linker script - 2 levels of indirection are involved (symbols and then to addresses referencing those symbols), and the addresses themselves can't be moved. I had some vague ideas about having one section per entry, and dealing with those sections in the linker script, but I didn't really get anywhere. If your concern is about baking in assumptions about avr-libc into binutils source code - I fully share it, but this was the only way I could get it to work. It still might be possible though; I'm hoping someone in the binutils mailing list would point it out if it is. Regards Senthil _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
