Re: [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information

[Wen Congyang <wency@cn.fujitsu.com>]

On 01/13/2015 07:30 PM, Ian Campbell wrote:
> On Tue, 2015-01-13 at 19:17 +0800, Wen Congyang wrote:
>> On 01/13/2015 06:11 PM, Ian Campbell wrote:
>>> On Tue, 2015-01-13 at 13:52 +0800, Wen Congyang wrote:
>>>> On 12/01/2014 10:21 PM, Euan Harris wrote:
>>>>> Tools debug builds are built with optimization level -O1, inherited from
>>>>> the CFLAGS definition in StdGNU.mk.   Optimizations confuse the debugger,
>>>>> and the comment justifying -O1 in StdGNU.mk should not apply for a
>>>>> userspace library.   Disable optimization by appending -O0 to CFLAGS,
>>>>> which overrides the -O1 flag specified earlier.
>>>>>
>>>>> Also specify -g3, to add macro debugging information which allows
>>>>> gdb to expand macro invocations.   This is useful as libxl uses many
>>>>> non-trivial macros.
>>>>>
>>>>> Signed-off-by: Euan Harris <euan.harris@citrix.com>
>>>>>
>>>>> Changes since v1:
>>>>>   * moved flag override to tools/Rules.mk so it affects all tools
>>>>> ---
>>>>>  tools/Rules.mk |    5 +++++
>>>>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/tools/Rules.mk b/tools/Rules.mk
>>>>> index 87a56dc..7ef1ce5 100644
>>>>> --- a/tools/Rules.mk
>>>>> +++ b/tools/Rules.mk
>>>>> @@ -54,6 +54,11 @@ CFLAGS_libxenvchan = -I$(XEN_LIBVCHAN)
>>>>>  LDLIBS_libxenvchan = $(SHLIB_libxenctrl) $(SHLIB_libxenstore) -L$(XEN_LIBVCHAN) -lxenvchan
>>>>>  SHLIB_libxenvchan  = -Wl,-rpath-link=$(XEN_LIBVCHAN)
>>>>>  
>>>>> +ifeq ($(debug),y)
>>>>> +# Disable optimizations and debugging information for macros
>>>>> +CFLAGS += -O0 -g3
>>>>> +endif
>>>>> +
>>>>>  LIBXL_BLKTAP ?= $(CONFIG_BLKTAP2)
>>>>>  
>>>>>  ifeq ($(LIBXL_BLKTAP),y)
>>>>>
>>>>
>>>> This patch causes a building error:
>>>> gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_TOOLS__ -MMD -MF .install.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc/include -Ixen/low
 level/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
>>>> In file included from /usr/include/limits.h:25:0,
>>>>                  from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:168,
>>>>                  from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/syslimits.h:7,
>>>>                  from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/limits.h:34,
>>>>                  from /usr/include/python2.7/Python.h:19,
>>>>                  from xen/lowlevel/xc/xc.c:7:
>>>> /usr/include/features.h:328:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
>>>
>>> Where is _FORTIFY_SOURCE coming from? I don't see it in our tree
>>> anywhere except stubdom/Makefile which is disabling it and the build
>>> worked for me. Perhaps it is coming from your build environment
>>> somewhere? How are you configuring and building Xen?
>>
>> _FORTIFY_SOURCE is just for python, and it comes from /usr/lib64/python2.7/config/Makefile:
>>
>> # Compiler options
>> OPT=            -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
>> BASECFLAGS=      -fno-strict-aliasing
>> CFLAGS=         $(BASECFLAGS) -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv  $(OPT) $(EXTRA_CFLAGS)
>>
> 
> That's a bit antisocial of it...
> 
> I can't reproduce this on Debian with Python 2.7. _FORTIFY_SOURCE=2 is
> not passed when building the Python bits (it is passed when linking,
> oddly). Debian's /usr/lib/python2.7/config-x86_64-linux-gnu/Makefile
> looks rather different to what you quote above though, it avoids bare
> CFLAGS for one thing (reserving them for the user).
> 
> I have a suspicion that this might be a bug in the Fedora Python
> packaging, in that they have leaked inappropriate build-time flags from
> the actual Python build into the set of flags to be used to build 3rd
> party Python modules.
> 
> Please can you check this with the Fedora folks? If they respond that
> this is deliberate etc then please let us know and we'll see what we can
> do in Xen to work around it.

Here is the reponse from Fedora folks:
-------- Forwarded Message --------
Subject: Re: [Xen-devel] [PATCH v2] tools/Rules.mk: Don't optimize debug builds; add macro debugging information
Date: Wed, 14 Jan 2015 12:22:19 -0500
From: Bohuslav Kabrda <bkabrda@redhat.com>
To: Wen Congyang <wency@cn.fujitsu.com>

----- Original Message -----
> Hi, bkabrda
> 
> When I build some python modules in xen, I find some building error.
> 
> The reason is that: we need to disable optimization by -O0, but
> the CFLAGS in python's Makefile have -Wp,-D_FORTIFY_SOURCE=2.
> 
> My question is that: Is this flag essential?
> 
> Thanks
> Wen Congyang

Hi,
all the flags come from default RPM build configuration that all Fedora packages are supposed to use. They are saved by Python's build process to config/Makefile. Running "setup.py build" then uses them for building extension modules. So to answer your question: yes, this is mandated by Fedora and will not go away.
Now, there are two solutions to your situation I can see:
- either add "undef_macros" to setup.py definition of the extension module, as documented at [1]
- run "setup.py build" in environment where you set "CFLAGS=-U_FORTIFY_SOURCE"
Both will do the same - undefine the _FORTIFY_SOURCE macro in the gcc invocations.

Hope this helps,
Slavek.

[1] https://docs.python.org/2/distutils/setupscript.html#preprocessor-options

> 
> Ian.
> 
> .
>