[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Senthil Kumar Selvaraj
Subject: Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry
Date: Fri, 15 Feb 2013 15:41:50 +0530
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]