Interrupts & Ravenscar

Interrupts & Ravenscar

[Simon Wright]

Interrupt handlers are specified as protected procedures, e.g.

   protected PO is
      ...
   private
      ...
      procedure Handler
      with Attach_Handler => Ada.Interrupts.Names.Foo_Interrupt;
   end PO;

declared at library level.

What should happen if I also write in the same partition

   protected Other_PO is
      ...
   private
      ...
      procedure Handler
      with Attach_Handler => Ada.Interrupts.Names.Foo_Interrupt;
   end Other_PO;

I'm specifically concerned with the Ravenscar profile. My
cortex-gnat-rts raises PE when the second PO is initialized; AdaCore's
ravenscar-full-stm32f4 doesn't - last in wins.

I found this because an AdaCore library had already declared a handler
for a particular interrupt, and I needed to implement my own
behaviour. In this case, I could ensure that my handler was used by the
proper elaboration pragmas. In other circumstances, e.g. attaching the
wrong interrupt, there might be long and tedious debugging sessions.

The ARM doesn't address this issue (aside from it being illegal in
Ravenscar to use any subprogram from Ada.Interrupts, which means that
the only control you have is via the elaboration order).

I would like to see PE being raised; would this be a suitable candidate
for an implementation restriction?

Re: Interrupts & Ravenscar

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyy3ogbdn2.fsf@pushface.org...
> I'm specifically concerned with the Ravenscar profile. My
> cortex-gnat-rts raises PE when the second PO is initialized; AdaCore's
> ravenscar-full-stm32f4 doesn't - last in wins.
>
> I found this because an AdaCore library had already declared a handler
> for a particular interrupt, and I needed to implement my own
> behaviour. In this case, I could ensure that my handler was used by the
> proper elaboration pragmas. In other circumstances, e.g. attaching the
> wrong interrupt, there might be long and tedious debugging sessions.
>
> The ARM doesn't address this issue (aside from it being illegal in
> Ravenscar to use any subprogram from Ada.Interrupts, which means that
> the only control you have is via the elaboration order).

C.3.1(14.1/3) says it is erroneous if aspect Attach_Handler is not used in a 
stack-like fashion. That implies that it ought to work if Attach_Handler is 
used twice. C.3.1(10) says that Program_Error is raised if the interrupt 
being attached is reserved (so that's probably what happened in your first 
case). Otherwise, the last one wins (which is what happened in your second 
case).

The intent appears to be that one would use subprograms to find out the 
previous handler and then call that (so it isn't lost), but of course you 
can't do that in Ravenscar.

In any case, I think the GNAT implementation is correct, in both cases 
(although it probably would be frendlier to reserve that interrupt if GNAT 
needs it in the Ravenscar version).

                                     Randy.