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

[Erik Christiansen]

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:

# Comandline: -Dvector_cutoff=11

   n = 0

   .macro bad_vector destination
   .ifdef vector_cutoff
      .if n < vector_cutoff
         JMP  \destination
      .endif 
   .else
      JMP  \destination
   .endif 

   n = n + 1         
   .endm             
  
   .macro good_vector destination
      JMP  \destination
   n = n + 1            
   .endm 

Doing the same for each vector in the linker script would be a lot of
visible clutter for a negligible number of bytes. Much better to do very
fine faffing behind the scenes, I submit.

Senthil, can you go with a -Dvector_cutoff=27, rather than an
--optimise_vectors? It is one thing for the user to get right, where
there was none, which is a penalty. Your binutils tweak is still the
only full solution.

Erik

-- 
I never pray before meals -- my mum's a good cook.