Re: [Xen-devel] [PATCH v2] Fix building error

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.01.15 at 12:26, <Ian.Jackson@xxxxxxxxxxxxx> 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 the right
> answer is for an affected developer 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.

Having run into this just now too, and seeing that the previous
discussion didn't really lead anywhere, I wonder what should be
done about this. I check as far back as I reasonably could, and
glibc apparently never supported _FORTIFY_SOURCE without
optimization. The change in behavior at some point simply was
that rather than disabling this silently, they now warn about it
(which of course is fatal for a build with -Werror). I also checked
Python, and they also seem to have been enabling
_FORTIFY_SOURCE forever. Consequently, with the previously
suggested patches not having found acceptance, how about

--- unstable.orig/tools/pygrub/Makefile
+++ unstable/tools/pygrub/Makefile
@@ -2,15 +2,17 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
+PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(APPEND_LDFLAGS)
+
 .PHONY: all
 all: build
 .PHONY: build
 build:
-       CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py build
+       CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install: all
-       CC="$(CC)" CFLAGS="$(CFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) setup.py 
install \
+       CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
                $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" \
                --install-scripts=$(LIBEXEC_BIN) --force
        set -e; if [ $(BINDIR) != $(LIBEXEC_BIN) -a \
--- unstable.orig/tools/python/Makefile
+++ unstable/tools/python/Makefile
@@ -4,6 +4,8 @@ include $(XEN_ROOT)/tools/Rules.mk
 .PHONY: all
 all: build
 
+PY_CFLAGS = $(patsubst -O0,-O1,$(CFLAGS)) $(LDFLAGS) $(APPEND_LDFLAGS)
+
 .PHONY: build
 build: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
                $(XEN_ROOT)/tools/libxl/idl.py
@@ -11,11 +13,11 @@ build: genwrap.py $(XEN_ROOT)/tools/libx
                $(XEN_ROOT)/tools/libxl/libxl_types.idl \
                xen/lowlevel/xl/_pyxl_types.h \
                xen/lowlevel/xl/_pyxl_types.c
-       CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) 
setup.py build
+       CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py build
 
 .PHONY: install
 install:
-       CC="$(CC)" CFLAGS="$(CFLAGS) $(LDFLAGS) $(APPEND_LDFLAGS)" $(PYTHON) 
setup.py install \
+       CC="$(CC)" CFLAGS="$(PY_CFLAGS)" $(PYTHON) setup.py install \
                $(PYTHON_PREFIX_ARG) --root="$(DESTDIR)" --force
 
 .PHONY: test

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel