This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, FranÃois Dumont <frs dot dumont at gmail dot com>
- Date: Thu, 10 Sep 2015 18:38:13 +0200
- Subject: Re: [patch] Enable lightweight checks with _GLIBCXX_ASSERTIONS.
- Authentication-results: sourceware.org; auth=none
- References: <20150907182755 dot GP2631 at redhat dot com> <87r3mauiud dot fsf at mid dot deneb dot enyo dot de> <20150907195939 dot GT2631 at redhat dot com> <55EEF828 dot 4060707 at redhat dot com> <20150908154535 dot GX2631 at redhat dot com> <55F05728 dot 1000209 at redhat dot com> <55F1B041 dot 5060507 at gmail dot com>
On 09/10/2015 06:30 PM, Martin Sebor wrote:
> On 09/09/2015 09:58 AM, Florian Weimer wrote:
>> On 09/08/2015 05:45 PM, Jonathan Wakely wrote:
>>
>>>> I doubt we can achieve the complexity goals in all cases. I expect
>>>> that
>>>>
>>>> for (int i = 0; i < 10000; ++i) {
>>>> vector[i];
>>>> }
>>>>
>>>> is optimized away in default mode, but with _GLIBCXX_ASSERTIONS, it is
>>>> not.
>>>>
>>>> The last time I looked at this, GCC was unable to move bounds checks
>>>> out
>>>> of loops.
>>>
>>> Maybe we don't want to make _FORTIFY_SOURCE imply _GLIBCXX_ASSERTIONS
>>> then, so they can be enabled independently. We don't have to make that
>>> decision right away.
>>
>> I think we should try with _FORTIFY_SOURCE first. The above case looks
>> rather artificial. If there is a visible performance impact, maybe we
>> can get the compiler to eliminate the vector bounds checks in many cases.
>
> There is quite a bit of documentation of _FORTIFY_SOURCE that explains
> its effect on user code.
I think there are only random blog articles discussing aspects of it,
most of them slightly incorrect or outdated.
> People who have read the documentation and
> used the macro to achieve the effect might find the secondary effects
> on libstdc++ surprising and unwelcome.
I think we should ask Fedora, Debian and others if they want to enable
the new libstdc++ checks as part of their standard hardening features.
If the answer is yes, we should tack it onto _FORTIFY_SOURCE, so that
they do not have to audit all their package build processes to include
the additional preprocessor #define.
This discussion comes up every time we make *any* change to
_FORTIFY_SOURCE. I'm not sure if it is that helpful because I haven't
seen much use of _FORTIFY_SOURCE outside distribution defaults. If
distributions are indeed the target audience for _FORTIFY_SOURCE, and
they want the additional hardening, I don't think it's necessary to
split it off (but it certainly makes sense to have a way to turn it off
separately, if only to show that a particularly performance issue is not
caused by the new hardening feature).
--
Florian Weimer / Red Hat Product Security