Hello,
I work currently on this ticket:
https://devel.rtems.org/ticket/4458
This is also related to the strange set_vector() function. 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 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?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
