This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] gcc fstack-protector-explicit
- From: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- To: Jeff Law <law at redhat dot com>
- Cc: Daniel Gutson <daniel dot gutson at tallertechnologies dot com>, Marcos Díaz <marcos dot diaz at tallertechnologies dot com>, "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 Jan 2015 10:07:14 +0100
- Subject: Re: [patch] gcc fstack-protector-explicit
- Authentication-results: sourceware.org; auth=none
- References: <CAEOtcjmFhFJ8A4r3nLq_odtFSctT51TOma0douMdBb27uKNnVA at mail dot gmail dot com> <528AFE96 dot 3040301 at redhat dot com> <CAEOtcjkX9yk5DXQbrKqxncpZJ0zvVdHq44jpL+6Bub9mH_t=DA at mail dot gmail dot com> <528D09D9 dot 9020902 at redhat dot com> <CAEOtcj=sXsqMOZw6Kas2iK=e6qRh5u+hmwB=-tmqAoWZL==5Dg at mail dot gmail dot com> <53B2EEEC dot 9030003 at redhat dot com> <CAF5HaEXvVgiGc3mexA5HL6ot5j7xObfNtqOgOsui6vTEZV5hGQ at mail dot gmail dot com> <54B75073 dot 4020501 at redhat dot com>
Jeff Law <law@redhat.com> writes:
> On 07/01/14 15:34, Daniel Gutson wrote:
>> On Tue, Jul 1, 2014 at 2:25 PM, Jeff Law <law@redhat.com> wrote:
>>> On 03/19/14 08:06, Marcos Díaz wrote:
>>>>
>>>> Well, finally I have the assignment, could you please review this patch?
>>>
>>> Thanks.
>>>
>>> My first thought was that if we've marked the function with an explicit
>>> static protector attribute, then it ought to be protected regardless of any
>>> flags. Is there some reason to require the -fstack-protect-explicit?
>>
>> They can work separately, since the logic is:
>>
>> if NOT stack-protect-explicit
>> a function can be protected by the current logic OR it has the attribute
>> (a function may be not automatically protected with the current logic)
>> ELSE // stack-protect-explicit
>> only functions marked with the attribute will be protected.
>>
>> IOW, when no stack-protect-explicit, the functions may not be
>> protected due to current logic, so the attribute acts as an override
>> to request protection.
> Sorry this took so long. I fixed a variety of whitespace errors, wrote a
> better ChangeLog, re-bootstrapped and regression tested the patch (given
> the long delay, I felt it was the least I could do). Approved and
> installed.
Unfortunately, the new gcc.dg/stackprotectexplicit1.c FAILs on Solaris
(both SPARC and x86):
FAIL: gcc.dg/stackprotectexplicit1.c (test for excess errors)
WARNING: gcc.dg/stackprotectexplicit1.c compilation failed to produce executable
Excess errors:
Undefined first referenced
symbol in file
__stack_chk_guard /var/tmp//ccv9aOr1.o
ld: fatal: symbol referencing errors. No output written to .
This doesn't occur on Linux since that defines TARGET_THREAD_SSP_OFFSET,
while Solaris (and doubtlessly other targets) need to link with -lssp to
get a definition of __stack_chk_guard.
The following patch does just that. Not yet tested because currently
trunk doesn't bootstrap (libstdc++.so link failure).
Ok for mainline once that has been done?
Thanks.
Rainer
2015-01-20 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* gcc.c (LINK_SSP_SPEC): Handle -fstack-protector-explicit.
# HG changeset patch
# Parent 32ee1d2fb4ac6498d6363a1841482f8c9fa521d7
Handle -fstack-protector-explicit in LINK_SSP_SPEC
diff --git a/gcc/gcc.c b/gcc/gcc.c
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -730,7 +730,7 @@ proper position among the other output f
#ifdef TARGET_LIBC_PROVIDES_SSP
#define LINK_SSP_SPEC "%{fstack-protector:}"
#else
-#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-strong|fstack-protector-all:-lssp_nonshared -lssp}"
+#define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-strong|fstack-protector-explicit|fstack-protector-all:-lssp_nonshared -lssp}"
#endif
#endif
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University