Unused macro: CPU_ISR_PASSES_FRAME_POINTER
gedare at rtems.org
Fri Aug 8 15:11:42 UTC 2014
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:
>>>> 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.
> So percpu.h needs to be fixed.
>>>> devel mailing list
>>>> devel at rtems.org
>>> 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
> 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
More information about the devel