Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Joel Sherrill]

On 8/8/2014 10:11 AM, Gedare Bloom wrote:
> 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.
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 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
>>

-- 
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