Atmega collecting and relaying interrupt calls

Question

I like to collect all possible interrupt and relay them to an alternative handler interrupt table what the user can set.

In order to do this i have to:
1) collect all/any interrup request
2) identify where is the interruption came from
3) relay the call to another table the user pointed.

If you familiar with interrupts you know if you registers a single function to all interrupt handler there's no way to idenfity the source of the interrupt. But registering unique interrupt handler that carries the information of the source and calls another function to dispatch call, for each interrupt is a code space wasting. Eg.: the atmega328 has 24 interrupt handlers. Each of the is compiled with the avr-gcc consumes 76 bytes.

---

But i have and idea how it is possible to register one handler function and identify the source:

00000000 <__vectors>:
   0:   0c 94 34 00     jmp 0x68    ; 0x68 <__ctors_end>
   4:   0c 94 51 00     jmp 0xa2    ; 0xa2 <__bad_interrupt>
   8:   0c 94 51 00     jmp 0xa2    ; 0xa2 <__bad_interrupt>
   c:   0c 94 51 00     jmp 0xa2    ; 0xa2 <__bad_interrupt>

If i define an interrupt handler (even if it can fit the 4 byte space) a jmp instruction is placed. If it can be replaced to eg.: call 0xa2 (which can fit in 4 bytes), is can be used to identify the interrupt source address.

Because call stores the return address, the function started at 0xa2 can read back that address and therefor idenfity the caller. Then add an extra pop (pop the stack address accumulated by the call at the interrup table) and reti (to return as like from an interrupt handler) after the function body.

If this can work theorically, to achieve this only one question remains:

How can i replace the jmp instructions to call in interrupt table?

Answer 1

The interrupt vector table is provided by the C runtime. It is not normally intended to be overridden by user code. You can, however, do it, if you replace the whole C run time by your own, and compile your sketch with the -nostartfiles option.

I have played this game once I was trying to accurately assess interrupt latencies. See the details in this answer (the answer is long, but you can go right to the last section).

Answer 2

The answer i've accepted is the proper answer for the problem i asked. However replacing the C runtime requires to attach and maintain a lot of crt.S files oiginally related to the GCC. To avoid this i "slept several times over this prolem" and came out another solution.

After compiling the host application that have to redirect the interrupt calls (script source). I wrote a utility that rewrites every interrupt jumps at the beginning of the ihex (source) with an offset to the target application.

Ok this solution doesn't collect and identify and relay the incoming interrupts, just relay them. As far as there's no target application, nothing enables these interrupts and cause fault. This solution also doesn't use extra code space.