Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Joel Sherrill]

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.

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