On Mon, May 9, 2016 at 12:48 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > On 5/9/2016 2:45 PM, Ian Lance Taylor wrote: >> >> On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill >> <joel.sherr...@oarcorp.com> wrote: >>> >>> >>> On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: >>>> >>>> >>>> On Fri, May 6, 2016 at 10:42 PM, Rich Felker <dal...@libc.org> wrote: >>>>> >>>>> >>>>> >>>>> The *context APIs are deprecated and I'm not sure they're worth >>>>> supporting with this. It would be a good excuse to get people to stop >>>>> using them. >>>> >>>> >>>> >>>> The gccgo library uses them, because there is no working alternative. >>> >>> >>> >>> FWIW when this transition occurred, that's when the RTEMS port broke. >>> We don't have these methods. >> >> >> Yes, that was unfortunate, but it was a significant increase in >> efficiency. >> >>> It would be an interesting exercise to see if they could be >>> implemented in terms of our internal thread context management >>> APIs but no one has ever looked into it deeply. >> >> >> They are short functions, and easy to implement. They don't need to >> use any thread context management, they just manipulate registers. >> The catch is that, because they manipulate registers, they are >> inherently machine-specific. > > > I suppose we could reuse implementations from *BSD for a subset > of targets. Those would likely be the targets folks care about > anyway. > > Hmm... would those make sense to add to newlib? I am thinking > they are similar to setjmp/longjmp and shouldn't need supervisor > mode access.
Makes sense to me. Ian
