Why is CPU_ISR_PASSES_FRAME_POINTER == FALSE on sparc?

[Joel Sherrill]

On Fri, Jun 18, 2021 at 9:23 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello,
>
> I work currently on this ticket:
>
> https://devel.rtems.org/ticket/4458
>
> This is also related to the strange set_vector() function.


set_vector() was added long ago as a BSP wrapper for rtems_interrupt_catch()
when all that was supported is what we now call simple vectored
architectures.
There were CPUs with a simple interrupt enable/disable bit in the processor
but
the board had an interrupt source mask register. Installing the vector was
not
enough to enable the interrupt. You have to touch the board's interrupt mask
register. That's where the method came from.

I count 104 references/uses in bsp/ and one in cpukit/ so it can't go away
without
some work.


> Why do we
> have this:
>
> /**
>   * Does the RTEMS invoke the user's ISR with the vector number and
>   * a pointer to the saved interrupt frame (1) or just the vector
>   * number (0)?
>   *
>   * The SPARC port does not pass an Interrupt Stack Frame pointer to
>   * interrupt handlers.
>   */
> #define CPU_ISR_PASSES_FRAME_POINTER FALSE
>

I'm guessing given the age of the SPARC port (started around 1994) that it
originally did not pass an ISR frame. Quite likely no port did at that
point.
When this macro was added, the SPARC port didn't define or  pass a
frame pointer.

At this point, I would say it is wrong.

>
> I noticed that in bsp_spurious_initialize() we use this default handler:
>
> static rtems_isr bsp_spurious_handler(
>     rtems_vector_number trap,
>     CPU_Interrupt_frame *isf
> )
> {
>    CPU_Exception_frame frame = {
>      .trap = trap,
>      .isf = isf
>    };
>
> We also have in cpu_asm.S:
>
>          sethi    %hi(SYM(_ISR_Vector_table)), %g4
>          or       %g4, %lo(SYM(_ISR_Vector_table)), %g4
>          and      %l3, 0xFF, %g5         ! remove synchronous trap
> indicator
>          sll      %g5, 2, %g5            ! g5 = offset into table
>          ld       [%g4 + %g5], %g4       ! g4 = _ISR_Vector_table[ vector ]
>
>
>                                          ! o1 = 2nd arg = address of the
> ISF
>                                          !   WAS LOADED WHEN ISF WAS
> SAVED!!!
>          mov      %l3, %o0               ! o0 = 1st arg = vector number
>          call     %g4
>
> So, why is CPU_ISR_PASSES_FRAME_POINTER set to FALSE when the handler is
> actually called with the frame pointer and some handler actually use it?
>

Looks like someone forgot to change the ifdef when they added the ISR frame.

Is the macro used anywhere?

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210618/8d51885b/attachment-0001.html>