This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SafeStack proposal in GCC


On Mon, May 9, 2016 at 12:48 PM, Joel Sherrill
<joel.sherrill@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.sherrill@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 <dalias@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]