Re: [Xen-devel] [PATCH 28/28] Separate runtime debug output from debug symbols

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.10.14 at 10:00, <olaf@xxxxxxxxx> wrote:
> On Thu, Oct 02, Jan Beulich wrote:
> 
>> >>> On 01.10.14 at 18:41, <olaf@xxxxxxxxx> wrote:
>> > --- a/xen/Rules.mk
>> > +++ b/xen/Rules.mk
>> > @@ -43,7 +43,8 @@ ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
>> >  
>> >  CFLAGS += -fno-builtin -fno-common
>> >  CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
>> > -CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
>> > +CFLAGS-$(debug_symbols) += -g
>> > +CFLAGS += -pipe -D__XEN__ -include $(BASEDIR)/include/xen/config.h
>> >  CFLAGS += -nostdinc
>> >  
>> >  CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
>> 
>> I'm fine with this change, but will make my ack depend on Andrew at
>> least not objecting (iirc he had reservations on a previous iteration).
> 
> Does that still stand? Quote:

Is that a question to me or to him?

> ...
>> I am not sure this is correct.  Xen needs to embed its full symbol
>> table for backtraces, so does need to be built unconditionally with -g
> 
> What does -g have to do with backtrace generation? If you're
> after .debug_frame, that can be had as .eh_frame without -g (and
> with -fasynchronous-unwind-tables passed instead). Yet whether
> everyone wants this is not at all clear, so providing a knob to turn  
> it on/off seems quite desirable to me.

My position didn't change, but I'm also not going to ignore his
comment. Hence my desire for him to clarify whether he objects
to the change (in which case I'd expect him to offer alternatives
aiming in this...

> The point of the change is that building with -g has most likely not
> much benefit for most users. Please clearify if -g is really a hard
> requirement to build the hypervisor.

... direction).

Jan


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