This is the mail archive of the gcc-patches@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: [Patch] Don't expand targetm.stack_protect_fail if it's NULL_TREE

From: Jeff Law <law at redhat dot com>
To: Jiong Wang <jiong dot wang at foss dot arm dot com>
Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
Date: Wed, 23 Nov 2016 14:40:22 -0700
Subject: Re: [Patch] Don't expand targetm.stack_protect_fail if it's NULL_TREE
Authentication-results: sourceware.org; auth=none
References: <c763d912-0806-7007-0381-807c94a9b746@foss.arm.com> <8d2e98cb-8474-b8ef-92f1-2d632419c493@redhat.com> <CAAfDdZ3ZvPMdao63eh-NyBo=mzKzUhVw5Aj++O494ok4Gf-9=A@mail.gmail.com> <705397b6-922e-713d-33bd-fbae3d2be68f@redhat.com> <ee850328-eb34-612b-604b-08b9df233aa9@foss.arm.com>

On 10/24/2016 10:29 AM, Jiong Wang wrote:

Right.  But your change could mask backend problems.  Specifically if

their expander for stack_protect_fail did fail and returned NULL_TREE.

That would cause it to silently ignore stack protector failures, which
seems inadvisable.

Is there another way you can re-use the analysis code without
resorting to something like this?


In my case, I only want the canary variable which is
"crtl->stack_protect_guard", then I don't want the current runtime
support which GCC will always generate once crl->stack_protect_guard is
initialized.

Presumably you're using this with the new AArch64 security features.ISTM we ought to be able to separate access to the guard from the restof the runtime bits.


Jeff

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