[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.
Regards
Senthil
- [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Senthil Kumar Selvaraj, 2013/02/14
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Weddington, Eric, 2013/02/14
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Georg-Johann Lay, 2013/02/14
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Weddington, Eric, 2013/02/14
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Georg-Johann Lay, 2013/02/14
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Senthil Kumar Selvaraj, 2013/02/15
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Georg-Johann Lay, 2013/02/15
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Ruud Vlaming, 2013/02/15
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Joerg Wunsch, 2013/02/16
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry,
Senthil Kumar Selvaraj <=
- Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Erik Christiansen, 2013/02/16
Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry, Oleksandr Redchuk, 2013/02/14