more patches more newlib-1.16.0 : setjmp & longjmp for 4.9 branch

[Till Straumann]

IIRC I had contributed a (maybe similar) patch in the past
which addressed saving/restoring FP context as part of
setjmp/longjmp.

Indeed, there were __rtems__ specific pieces:

 - on rtems not all threads are necessarily FP-enabled
 - on rtems lazy-FP context switching is possible
 - on rtems we can read MSR to find out if the FPU is
   enabled or not (since we run in supervisory mode).

-> my patch (#ifdef __rtems__ only) used the MSR[FE]
   information to dump/load FP registers when possible/necessary.

Under these premises the test for __rtems__ seems to
make sense but you might have a better idea.

BTW: a similar issue arises with setjmp/longjmp
when should handle altivec registers.

T.

P.S: at some point, IIRC, as a work-around, all
      threads were made FP threads implicitly
      because of some gcc version's implicit use
      of the FPU for integer operations.
      I don't know if this work-around is still
      in place and/or necessary with the latest gcc.

      If all threads are FP-enabled then a newlib patch
      should not be necessary.

Ralf Corsepius wrote:
> Joel Sherrill wrote:
>   
>> Kate Feng wrote:
>>     
>>> Ralf Corsepius wrote:
>>>   
>>>       
>>>> Kate Feng wrote:
>>>>     
>>>>         
>>>>> Hi,
>>>>>
>>>>> Attached is the patches for newlib-1.16.0.  The setjmp() and longjmp()
>>>>> are broken, which could affect their function in the 4.9. branch.
>>>>> The patch for the setjmp.S is only for powerPC port, which was tested
>>>>> for my applications.  The path for the setjmp.h should be applied to
>>>>> all platforms.
>>>>>       
>>>>>           
>>>> Some questions:
>>>>
>>>> * Which bug is this patch supposed to fix?
>>>> Please elaborate.
>>>>
>>>> * Whatever you are trying to fix, is almost certainly not RTEMS 
>>>> specific but architecture specific
>>>> => Your use of  __rtems__ is not the "right way" to do it.
>>>>
>>>>     
>>>>         
>> I think I remember this patch and there was some reason
>> you needed to know you were in supervisor mode in the
>> environment to do it.  That's what the __rtems__ was for.
>>     
> Without knowing the cause, I don't see any reason of applying this patch.
>
>   
>> I don't recall what the purpose of the patch is though
>>     
>>> The machine/powerpc/setjmp.S file is probably only linked to powerPC port.
>>>       
> No. This file is shared with other powerpc targets in newlib.
>
>   
>>> Thus, it's  probably OK.  However, setjmp() , when called, will trigger 
>>> the error
>>> message of :
>>> "In BSP_exceptionHandler()
>>> Uhuuuh, Exception 10 in unknown task???".
>>> Using  sigsetjmp(buf, 1) did not solve the problem.  Thus,
>>> I simply apply the patch from the newlib1.15.0, which I used for the
>>> RTEMS4.8.0.  Perhaps, it was implemented wrongly in 4.8 , instead ?
>>>
>>> I agree with you that the patch fixes the problem, but ties its function 
>>> to architecture
>>> specific.  At this point, I do remember reading about that 'setjmp' and 
>>> 'longjmp'
>>> should be used carefully that there are  other more graceful ways to 
>>> handle it.
>>> This is my memory from last century that I guess I would have to dig 
>>> into for
>>> the more elegant solution........
>>>
>>> Thanks a lot for your pointer.  Perhaps, it is better not to apply the 
>>> patch so that
>>> it does not add architecture specific patch......  Please advise.
>>>       
> My point is: machine/powerpc/setjmp.S is not RTEMS specific, but a file 
> which is shared between all newlib powerpc targets.
>
> So, we need to exactly know which issue it is your patch tries to work 
> around and under which conditions the changes your patch implements are 
> needed.
>
> The condition hardly is "#if __rtems__", but is something else.
>
> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>