Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Gedare Bloom]

On Fri, Aug 8, 2014 at 10:52 AM, Joel Sherrill
<joel.sherrill at 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.sherrill at 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.
-Gedare
> So percpu.h needs to be fixed.
>>>> Gedare
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>> joel.sherrill at 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 at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>