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

[Senthil Kumar Selvaraj]

On Sat, Feb 16, 2013 at 10:09:08PM +1100, Erik Christiansen wrote:
> TL;DR: There is a workaround at the end. Is its lower intrusiveness
>        better balanced against the small optimisation, than the
>        binutils tweak which provides full automation? Whatever. ;-)
> 
> On 15.02.13 15:41, Senthil Kumar Selvaraj wrote:
> > On Fri, Feb 15, 2013 at 08:31:42AM +0100, Georg-Johann Lay wrote:
> > > Does this really need binutils changes, or could it be achieved by
> > > linker script improvements, e.g. start .text after the last .vector?
> 
> It is automatic detection of the start of the "bad vectors" tail, prior
> to the end of the vector table, which is more than difficult for both
> gas and ld.
> 
> > > 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.
> 
> That level of semantics whizzes way over the linker's head, since the
> language makes no attempt to deal with indirection, AFAICT. Also,
> iterating over an array of addresses is not available.
> 
> > 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.
> 
> Yes, individual input sections flitted through my mind too, on reading
> the OP, but without any relevant information from the compiler, other
> than that no used vector follows the tail of "bad vectors", ld is hard
> pressed to perform this optimisation. Rereading "3.10.5 Evaluation" in
> "info ld" reminds us why. (Just as conditional assembly also fails if we
> try to do it with gas instead: 'Error: non-constant expression in ".if"
> statement')
> 
> As you've pointed out, even -ffunction-sections needs additional
> selection information, which doesn't exist, greatly amplifying the
> challenge.
> 
> Granted, the (saved memory) reward for the effort is small, but if the
> user would specify the number of the highest used vector, then gas
> conditional assembly, in a "bad vector" macro does handle the task:

Ah, but right now, the vector table is defined in avr-libc
(crt1/gcrt1.S) and gets built into crtxxx.o at avr-libc build time. It
is then linked into the final executable automatically by the gcc
driver. I guess that rules out conditional assembly?

Regards
Senthil