Kinsey Moore started a new discussion on bsps/mips/shared/irq/vectorexceptions.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1401#note_158424 > { > - (void) frame; > - > uint32_t cause; > uint32_t exc; > > mips_get_cause( cause ); > exc = (cause >> 2) & 0x1f; > > + if ( exc == MIPS_EXCEPTION_RI && mips_emulate_rdhwr_ulr( frame ) ) { > + return; > + } > + > mips_exception_frame = frame; > bsp_interrupt_handler_dispatch( exc ); > mips_exception_frame = NULL; You didn't add the current MIPS exception control flow, but it seems hacky and significantly out of date compared to other architectures supported in RTEMS. Adding the TLS invalid instruction intercept functionality here makes it slightly more disjoint. This functionality would be a prime candidate for implementation as a fatal error hook using exception extensions. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1401#note_158424 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-7yzulp4yn22sv8sgcpqvq4jog-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
