[task #7546] Rework the default interrupt handler

[avrs-admin]

Sat 22 Dec 2007 09:34:53 PM CET

Right now, the default interrupt handler eventually ends up
in restarting the application at address 0, so the user-
visible effect is almost similar to a reset, which has turned
out to cause minor surprises occasionally.

Other ideas have been discussed about the default ISR.  Just
using a RETI is not really better: some interrupts are not
auto-clearing so they would end up in an infinite loop, and
in all other cases a missing ISR is a programming error most
of the time which would go completely unnoticed for a long
time then.

The best idea so far came once from Peter Dannegger.  He
suggested to CALL/RCALL the default handler from within the
vector table, rather than JMP/RJMP to it.  That way, the
default handler can then pop the return address into a register
where it can be examined with a debugger (or inside the default
handler itself if it's a custom handler).  That way, programmers
will get an idea what interrupt triggered.

Finally, the default handler should best run into an infinite
loop with interrupts disabled.  abort() has been suggested a
possible implementation for that which is already there.

The difficulty of this idea is that the current scheme to
fill the vector table with JMP/RJMP instructions to locations
that are eventually inserted by the linker won't work anymore.
A new scheme would be needed where by default, a CALL/RCALL
is placed into the slot, and is then replaced by a jump
instructions for all vectors that are actually defined by
the application.

This issue was migrated from https://savannah.nongnu.org/task/?7546

[avrs-admin]

Eric Weddington
Fri 13 May 2011 01:04:52 AM CEST

Good ideas still here. Any more thoughts on moving this forward?

[sprintersb]

The difficulty of this idea is that the current scheme to
fill the vector table with JMP/RJMP instructions to locations
that are eventually inserted by the linker won't work anymore.

This should be possible, for example by means of a new pseudo instruction.

The problem with that solution is that we don't know which Binutils version is used with crt*.o because the crt's may come as part of a device pack, which bypasses all efforts by configure etc.

Currently, crt*.o works with all versions of Binutils and the compiler, so using such pseudo instruction would break that; and I don't see any backwards compatible way to implement it.

...maybe like so: The linker transforms JMP to CALL in, say, relaxation, but only when a specific symbol is defined. That way one has control over the feature without the requirement of a new command line option.