I can use this in my port from my assembly code part of _ISR_Handler just before calling the user C Handler. Something like putting #if CPU_ISR_PASSES_FRAME_POINTER l.add r4, sp, r0 #endif
where r3 and r4 are the first and second arguments respectively. RTEMS Clock_isr() (which I use for tick timer interrupt) and maybe other RTEMS C Handlers may not make use of it as some of them are defined with void arguments. As Gedare suggested, I provided a default _OR1K_Exception_default that receives vector number and exception frame pointer. On Fri, Aug 8, 2014 at 5:13 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > On 8/8/2014 10:11 AM, Gedare Bloom wrote: >> On Fri, Aug 8, 2014 at 10:52 AM, Joel Sherrill >> <joel.sherr...@oarcorp.com> wrote: >>> On 8/8/2014 9:38 AM, Hesham Moustafa wrote: >>>> On Fri, Aug 8, 2014 at 4:02 PM, Joel Sherrill <joel.sherr...@oarcorp.com> >>>> wrote: >>>>> On 8/8/2014 8:54 AM, Gedare Bloom wrote: >>>>>> Hi, >>>>>> The macro CPU_ISR_PASSES_FRAME_POINTER is part of a cpu port defined >>>>>> in cpu.h, but this macro seems to be unused. I don't know what the >>>>>> purpose of it was intended. Anyway, it appears to be wrong for some >>>>>> architectures (ARM and sparc64 at least, maybe others). Should we >>>>>> remove the macro, or find a use for it and make sure it is correctly >>>>>> defined for each arch? >>>>> The intent is that for simple vectored, some architectures passed a vector >>>>> number and some passed a vector number and a pointer to the interrupt >>>>> stack frame. This predates the addition of the PIC model. >>>>> >>>>> In general terms, I don't know if all simple vectored architectures >>>>> pass one or two parameters. >>>>> >>>>> Is this used anywhere in the tree? Sometimes drivers would use it to >>>>> adjust the ISR handler prototype to avoid warnings. >>>> It's used only at isr.h:62 >>>> >>>> 62 #if (CPU_ISR_PASSES_FRAME_POINTER == 1) >>>> 63 typedef ISR_Handler ( *ISR_Handler_entry )( >>>> 64 ISR_Vector_number, >>>> 65 CPU_Interrupt_frame * >>>> 66 ); >>>> 67 #else >>>> 68 typedef ISR_Handler ( *ISR_Handler_entry )( >>>> 69 ISR_Vector_number >>>> 70 ); >>>> 71 #endif >>> But that has rippling implications. I don't think we want to >>> change that at the moment. But we could turn it to 1 for >>> every architecture and see the impact. But most architectures >>> have it as single arg. I know the MIPS passes it in so it can >>> handle FPU exceptions in an RTEMS ISR. To get IEEE FP >>> on some MIPS, you need the exception handler. >>> >>> All other ports set this to FALSE/0. >>> >> Well, so far I've seen that arm, sparc, and sparc64 pass the frame >> pointer. i386 does not. > The setting doesn't seem right for those. I only saw 1/true for MIPS. > > It could be wrong for those. >> -Gedare >>> So percpu.h needs to be fixed. >>>>>> Gedare >>>>>> _______________________________________________ >>>>>> devel mailing list >>>>>> devel@rtems.org >>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>> -- >>>>> Joel Sherrill, Ph.D. Director of Research & Development >>>>> joel.sherr...@oarcorp.com On-Line Applications Research >>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>>>> Support Available (256) 722-9985 >>>>> >>>>> _______________________________________________ >>>>> devel mailing list >>>>> devel@rtems.org >>>>> http://lists.rtems.org/mailman/listinfo/devel >>> -- >>> Joel Sherrill, Ph.D. Director of Research & Development >>> joel.sherr...@oarcorp.com On-Line Applications Research >>> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >>> Support Available (256) 722-9985 >>> > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
