From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2] Fix building error Date: Mon, 19 Jan 2015 15:23:48 +0000 Message-ID: <1421681028.10440.108.camel@citrix.com> References: <1417435968.29138.19.camel@citrix.com> <1417443665-30809-1-git-send-email-euan.harris@citrix.com> <54B73658.6030309@cn.fujitsu.com> <20150115075746.GA22946@aepfle.de> <54B7829A.4080902@cn.fujitsu.com> <20150115092132.GA15492@aepfle.de> <54B78828.3000509@cn.fujitsu.com> <54B78967.7090604@cn.fujitsu.com> <21687.41950.236527.898465@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21687.41950.236527.898465@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Olaf Hering , Euan Harris , Wen Congyang , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, 2015-01-15 at 11:26 +0000, Ian Jackson wrote: > Wen Congyang writes ("[PATCH v2] Fix building error"): > > ifeq ($(debug),y) > > # Disable optimizations and enable debugging information for macros > > CFLAGS += -O0 -g3 > > +# _FORTIFY_SOURCE requires compiling with optimization > > +CFLAGS += -Wp,-U_FORTIFY_SOURCE > > I'm not entirely convinced about this. I have two kinds of concern: > > One is practical, which is that ATM AIUI a debug build, while not > intended for production use, is not any less secure. (Leaving aside > the ability of guests to perform a DoS with copious debugging output.) > > The other is that we seem to be entering into a battle of escalation > between various Makefiles. Specifically, this seems to be a > workaround for a bug in some other Makefiles we are using: the bug > being that these other Makefiles can't cope with -O0. And > unconditionally squashing the other Makefiles' options seems like a > big hammer. > > The fact that Fortify doesn't support -O0 is a property of Fortify > which ought to be encoded in Fortify (or the places where it is > enabled). > > Assuming that the underlying bug is intractible I think so, see <54B73623.9040503@cn.fujitsu.com>. I suppose one could enter into a dialogue with Fedora about the practice of enabling these flags for all Python modules built on a Fedora system vs. just those built via RPM etc. > I think the right > answer is for an affected developer Which will be all developers using Fedora AFAICT. > to do one of the following, as a > workaround: either, manually override Fortify when requesting a debug > build (by setting EXTRA_CFLAGS_XEN_TOOLS), or manually override the > -O0 setting. > > To make this easier to do without editing tools/Rules.mk I would > support a patch to Rules.mk which has it honour a variable containing > a debug-specific set of CFLAGS. This seems reasonable enough to me. The original patch in <54B73658.6030309@cn.fujitsu.com> (correctly IMHO) applied the workaround only to the Python parts of the build (tools/{python,pygrub}) whereas this v2 and your suggestion would affect all of tools/*. That seems like a reasonable compromise under the circumstances (the alternative being special overrides for Python or something, no nice). Ian.