[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more patches more newlib-1.16.0 : setjmp & longjmp for 4.9 branch
- Date: Mon, 02 Mar 2009 19:33:37 -0800
- From: strauman at slac.stanford.edu (Till Straumann)
- Subject: more patches more newlib-1.16.0 : setjmp & longjmp for 4.9 branch
IIRC I had contributed a (maybe similar) patch in the past
which addressed saving/restoring FP context as part of
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.
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:
>>>>> 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
>>> 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
> The condition hardly is "#if __rtems__", but is something else.
> rtems-users mailing list
> rtems-users at rtems.com