This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Ian Lance Taylor <iant at google dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: Rich Felker <dalias at libc dot org>, Volodymyr Kuznetsov <vova dot kuznetsov at epfl dot ch>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 9 May 2016 12:51:52 -0700
- Subject: Re: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
- References: <CAFA9rWPkb=eV0GhvFeOnd4pRVh=N3fSifYBwZjy9Ndh68BmBww at mail dot gmail dot com> <0d50f0ef01b24c25a79a6f18eaddfd6d at REXA dot intranet dot epfl dot ch> <CANL6WeqEwFYx2H-sv81K8CDFypiJ+ray+xPyRH+7kitTpD8bqw at mail dot gmail dot com> <20160507054212 dot GE21636 at brightrain dot aerifal dot cx> <CAKOQZ8zYdRgjsg0D5oVfXkkadzkyybKZn3nnG8RBs5hLNq7Neg at mail dot gmail dot com> <c92fb63c-9450-e829-4dfd-5c84ac5bb782 at oarcorp dot com> <CAKOQZ8wG-qarBCNp61q+T_LXg4Dihdj=FWkx7R9bgbyY6dpKqw at mail dot gmail dot com> <64e5172c-ceb7-fc41-d2fb-f8705ff52139 at oarcorp dot com>
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