Wrap Interrupt Handlers for Recording?

[Sebastian Huber]

----- Am 5. Sep 2019 um 7:25 schrieb Chris Johns chrisj at rtems.org:

> On 5/9/19 2:25 pm, Sebastian Huber wrote:
>> ----- Am 4. Sep 2019 um 23:41 schrieb Chris Johns chrisj at rtems.org:
>> 
>>> On 5/9/19 2:09 am, Sebastian Huber wrote:
>>>> Hello,
>>>>
>>>> I would like to wrap calls to interrupt handlers which use the generic interrupt
>>>> framework (<rtems/irq-extension.h>) to get RTEMS_RECORD_INTERRUPT_ENTRY and
>>>> RTEMS_RECORD_INTERRUPT_EXIT events. This cannot be done by the linker since the
>>>> loop to call the handlers is inlined due to performance reasons. I would like
>>>> to add some sort of a callback mechanism which is invoked in
>>>> rtems_interrupt_handler_install() and rtems_interrupt_handler_remove()
>>>> operations (similar to the user extensions). There are some options to do this.
>>>>
>>>> 1. A new linker set with functions.
>>>>
>>>> 2. A new user extension, maybe a generic:
>>>>
>>>>   void (*event)(rtems_extension_event event, void *arg);
>>>>
>>>> 3. An API to install/remove a specific callback for this purpose.
>>>>
>>>
>>> 4. Update or add a new API call to return the currently installed
>>>    handler. This way interrupts can be chained.
>> 
>> This API already exists:
>> 
>> https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html#ga31d23275b676018c06e13c7bedc87983
>> 
>> The problem with this approach is that it doesn't wrap new handlers and if you
>> remove a wrapped handler, then a memory leak or worse may happen.
> 
> Yes care needs to be taken with this approach.
> 
>> 
>>>
>>>> I am in favour of 1. I also would like to hide it from the user for now.
>>>
>>> Does 1. allow runtime installing and then tracing of an interrupt? I know 3.
>>> would.
>> 
>> Yes, 1., 2., and 3. do the same, the difference is how you install the wrapper
>> functionality and maybe how many you can install.
> 
> It is difficult because you may want to trace one of a number of interrupt
> sources or you may want to trigger tracing of another event due to system
> issues.

For this complex scenario the proposed approach is not the right tool. To trace individual interrupts, you can wrap the specific interrupt handler and do your complex stuff.

> 
>> 
>> 5. Use a weak function.
>> 
> 
> Would this mean the overhead of the weak function happens all the time?

I mean weak functions which are called during interrupt handler install/remove. The interrupt dispatching should remain as is with absolutely no overhead if recording is disabled.