* [dpdk-dev] [PATCH] mk: add support for gdb debug info generation @ 2014-04-03 17:31 Cyril Chemparathy 2014-04-04 9:57 ` Ananyev, Konstantin 0 siblings, 1 reply; 22+ messages in thread From: Cyril Chemparathy @ 2014-04-03 17:31 UTC (permalink / raw) To: dev It is often useful to build with debug enabled, we add a config (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. Note: This patch does not include corresponding changes for ICC. The author pleads abject ignorance in this regard, and welcomes recommendations. :-) Signed-off-by: Cyril Chemparathy <cchemparathy@tilera.com> --- config/defconfig_x86_64-default-linuxapp-gcc | 1 + mk/toolchain/gcc/rte.vars.mk | 5 +++++ 2 files changed, 6 insertions(+) diff --git a/config/defconfig_x86_64-default-linuxapp-gcc b/config/defconfig_x86_64-default-linuxapp-gcc index f11ffbf..3b36efd 100644 --- a/config/defconfig_x86_64-default-linuxapp-gcc +++ b/config/defconfig_x86_64-default-linuxapp-gcc @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y +CONFIG_RTE_TOOLCHAIN_DEBUG=n # # Use intrinsics or assembly code for key routines diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 0edb93f..81ed3fa 100644 --- a/mk/toolchain/gcc/rte.vars.mk +++ b/mk/toolchain/gcc/rte.vars.mk @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif endif +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) +TOOLCHAIN_CFLAGS += -g -ggdb +TOOLCHAIN_LDFLAGS += -g -ggdb +endif + WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual -- 1.8.3.1 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2014-04-03 17:31 [dpdk-dev] [PATCH] mk: add support for gdb debug info generation Cyril Chemparathy @ 2014-04-04 9:57 ` Ananyev, Konstantin 2015-02-22 11:51 ` Marc Sune 0 siblings, 1 reply; 22+ messages in thread From: Ananyev, Konstantin @ 2014-04-04 9:57 UTC (permalink / raw) To: Cyril Chemparathy, dev Hi Cyril, We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use to enable debug, or any other compiler/linker options you need. Wonder, why that is not enough? Thanks Konstantin -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Cyril Chemparathy Sent: Thursday, April 03, 2014 6:31 PM To: dev@dpdk.org Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation It is often useful to build with debug enabled, we add a config (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. Note: This patch does not include corresponding changes for ICC. The author pleads abject ignorance in this regard, and welcomes recommendations. :-) Signed-off-by: Cyril Chemparathy <cchemparathy@tilera.com> --- config/defconfig_x86_64-default-linuxapp-gcc | 1 + mk/toolchain/gcc/rte.vars.mk | 5 +++++ 2 files changed, 6 insertions(+) diff --git a/config/defconfig_x86_64-default-linuxapp-gcc b/config/defconfig_x86_64-default-linuxapp-gcc index f11ffbf..3b36efd 100644 --- a/config/defconfig_x86_64-default-linuxapp-gcc +++ b/config/defconfig_x86_64-default-linuxapp-gcc @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y +CONFIG_RTE_TOOLCHAIN_DEBUG=n # # Use intrinsics or assembly code for key routines diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 0edb93f..81ed3fa 100644 --- a/mk/toolchain/gcc/rte.vars.mk +++ b/mk/toolchain/gcc/rte.vars.mk @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif endif +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) +TOOLCHAIN_CFLAGS += -g -ggdb +TOOLCHAIN_LDFLAGS += -g -ggdb +endif + WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual -- 1.8.3.1 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2014-04-04 9:57 ` Ananyev, Konstantin @ 2015-02-22 11:51 ` Marc Sune 2015-03-02 17:32 ` Marc Sune 0 siblings, 1 reply; 22+ messages in thread From: Marc Sune @ 2015-02-22 11:51 UTC (permalink / raw) To: dev I don't like the proposed patch, but I am recovering this old thread because I agree on the problem statement. On 04/04/14 11:57, Ananyev, Konstantin wrote: > Hi Cyril, > We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use to enable debug, or any other compiler/linker options you need. > Wonder, why that is not enough? EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why setting individually: diff --git a/config/common_linuxapp b/config/common_linuxapp index 2f9643b..04adc0d 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y # Compile generic ethernet library # CONFIG_RTE_LIBRTE_ETHER=y -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y to put an example, does not set -g and -O0 in that particular module only. No one would ever use something compiled in DEBUG in production anyway. I always end up modifying manually Makefiles in the lib library that I am interested in having insides, overriding CFLAGS=-O3, which is not that nice. Marc > Thanks > Konstantin > > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Cyril Chemparathy > Sent: Thursday, April 03, 2014 6:31 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation > > It is often useful to build with debug enabled, we add a config > (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. > > Note: This patch does not include corresponding changes for ICC. The author pleads abject ignorance in this regard, and welcomes recommendations. :-) > > Signed-off-by: Cyril Chemparathy <cchemparathy@tilera.com> > --- > config/defconfig_x86_64-default-linuxapp-gcc | 1 + > mk/toolchain/gcc/rte.vars.mk | 5 +++++ > 2 files changed, 6 insertions(+) > > diff --git a/config/defconfig_x86_64-default-linuxapp-gcc b/config/defconfig_x86_64-default-linuxapp-gcc > index f11ffbf..3b36efd 100644 > --- a/config/defconfig_x86_64-default-linuxapp-gcc > +++ b/config/defconfig_x86_64-default-linuxapp-gcc > @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" > CONFIG_RTE_TOOLCHAIN_GCC=y > +CONFIG_RTE_TOOLCHAIN_DEBUG=n > > # > # Use intrinsics or assembly code for key routines diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 0edb93f..81ed3fa 100644 > --- a/mk/toolchain/gcc/rte.vars.mk > +++ b/mk/toolchain/gcc/rte.vars.mk > @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif endif > > +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) > +TOOLCHAIN_CFLAGS += -g -ggdb > +TOOLCHAIN_LDFLAGS += -g -ggdb > +endif > + > WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual > -- > 1.8.3.1 > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-02-22 11:51 ` Marc Sune @ 2015-03-02 17:32 ` Marc Sune 2015-03-03 9:33 ` Bruce Richardson 0 siblings, 1 reply; 22+ messages in thread From: Marc Sune @ 2015-03-02 17:32 UTC (permalink / raw) To: dev On 22/02/15 12:51, Marc Sune wrote: > I don't like the proposed patch, but I am recovering this old thread > because I agree on the problem statement. > > On 04/04/14 11:57, Ananyev, Konstantin wrote: >> Hi Cyril, >> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can >> use to enable debug, or any other compiler/linker options you need. >> Wonder, why that is not enough? > > EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why > setting individually: > > diff --git a/config/common_linuxapp b/config/common_linuxapp > index 2f9643b..04adc0d 100644 > --- a/config/common_linuxapp > +++ b/config/common_linuxapp > @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y > # Compile generic ethernet library > # > CONFIG_RTE_LIBRTE_ETHER=y > -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n > +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y > > > to put an example, does not set -g and -O0 in that particular module > only. No one would ever use something compiled in DEBUG in production > anyway. > > I always end up modifying manually Makefiles in the lib library that I > am interested in having insides, overriding CFLAGS=-O3, which is not > that nice. I would like some feedback on this idea. If the community sees benefit, I will work on a patch for this. Marc > > Marc > >> Thanks >> Konstantin >> >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Cyril Chemparathy >> Sent: Thursday, April 03, 2014 6:31 PM >> To: dev@dpdk.org >> Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info >> generation >> >> It is often useful to build with debug enabled, we add a config >> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. >> >> Note: This patch does not include corresponding changes for ICC. The >> author pleads abject ignorance in this regard, and welcomes >> recommendations. :-) >> >> Signed-off-by: Cyril Chemparathy <cchemparathy@tilera.com> >> --- >> config/defconfig_x86_64-default-linuxapp-gcc | 1 + >> mk/toolchain/gcc/rte.vars.mk | 5 +++++ >> 2 files changed, 6 insertions(+) >> >> diff --git a/config/defconfig_x86_64-default-linuxapp-gcc >> b/config/defconfig_x86_64-default-linuxapp-gcc >> index f11ffbf..3b36efd 100644 >> --- a/config/defconfig_x86_64-default-linuxapp-gcc >> +++ b/config/defconfig_x86_64-default-linuxapp-gcc >> @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" >> CONFIG_RTE_TOOLCHAIN_GCC=y >> +CONFIG_RTE_TOOLCHAIN_DEBUG=n >> # >> # Use intrinsics or assembly code for key routines diff --git >> a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index >> 0edb93f..81ed3fa 100644 >> --- a/mk/toolchain/gcc/rte.vars.mk >> +++ b/mk/toolchain/gcc/rte.vars.mk >> @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif >> endif >> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) >> +TOOLCHAIN_CFLAGS += -g -ggdb >> +TOOLCHAIN_LDFLAGS += -g -ggdb >> +endif >> + >> WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes >> -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations >> -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align >> -Wnested-externs -Wcast-qual >> -- >> 1.8.3.1 >> > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-02 17:32 ` Marc Sune @ 2015-03-03 9:33 ` Bruce Richardson 2015-03-03 12:19 ` Marc Sune 0 siblings, 1 reply; 22+ messages in thread From: Bruce Richardson @ 2015-03-03 9:33 UTC (permalink / raw) To: Marc Sune; +Cc: dev On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: > > On 22/02/15 12:51, Marc Sune wrote: > >I don't like the proposed patch, but I am recovering this old thread > >because I agree on the problem statement. > > > >On 04/04/14 11:57, Ananyev, Konstantin wrote: > >>Hi Cyril, > >>We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use > >>to enable debug, or any other compiler/linker options you need. > >>Wonder, why that is not enough? > > > >EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why > >setting individually: > > > >diff --git a/config/common_linuxapp b/config/common_linuxapp > >index 2f9643b..04adc0d 100644 > >--- a/config/common_linuxapp > >+++ b/config/common_linuxapp > >@@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y > > # Compile generic ethernet library > > # > > CONFIG_RTE_LIBRTE_ETHER=y > >-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n > >+CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y > > > > > >to put an example, does not set -g and -O0 in that particular module only. > >No one would ever use something compiled in DEBUG in production anyway. > > > >I always end up modifying manually Makefiles in the lib library that I am > >interested in having insides, overriding CFLAGS=-O3, which is not that > >nice. > > I would like some feedback on this idea. If the community sees benefit, I > will work on a patch for this. > > Marc > So, your proposal is to patch things so that any time one sets DEBUG=y in the build-time config for a library, we change the '-O3' to '-O0' and set -g also. Correct? If that's the case, I see no harm in doing such a thing. I wonder how useful the '-g' option would be, just limited to a single library, though. One would suspect that it may be better applied globally, so that one can see the state of the application as it makes the call into the library. /Bruce > > > >Marc > > > >>Thanks > >>Konstantin > >> > >>-----Original Message----- > >>From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Cyril Chemparathy > >>Sent: Thursday, April 03, 2014 6:31 PM > >>To: dev@dpdk.org > >>Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info > >>generation > >> > >>It is often useful to build with debug enabled, we add a config > >>(CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. > >> > >>Note: This patch does not include corresponding changes for ICC. The > >>author pleads abject ignorance in this regard, and welcomes > >>recommendations. :-) > >> > >>Signed-off-by: Cyril Chemparathy <cchemparathy@tilera.com> > >>--- > >> config/defconfig_x86_64-default-linuxapp-gcc | 1 + > >> mk/toolchain/gcc/rte.vars.mk | 5 +++++ > >> 2 files changed, 6 insertions(+) > >> > >>diff --git a/config/defconfig_x86_64-default-linuxapp-gcc > >>b/config/defconfig_x86_64-default-linuxapp-gcc > >>index f11ffbf..3b36efd 100644 > >>--- a/config/defconfig_x86_64-default-linuxapp-gcc > >>+++ b/config/defconfig_x86_64-default-linuxapp-gcc > >>@@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" > >> CONFIG_RTE_TOOLCHAIN_GCC=y > >>+CONFIG_RTE_TOOLCHAIN_DEBUG=n > >> # > >> # Use intrinsics or assembly code for key routines diff --git > >>a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index > >>0edb93f..81ed3fa 100644 > >>--- a/mk/toolchain/gcc/rte.vars.mk > >>+++ b/mk/toolchain/gcc/rte.vars.mk > >>@@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif > >>endif > >> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) > >>+TOOLCHAIN_CFLAGS += -g -ggdb > >>+TOOLCHAIN_LDFLAGS += -g -ggdb > >>+endif > >>+ > >> WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes > >>-Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations > >>-Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align > >>-Wnested-externs -Wcast-qual > >>-- > >>1.8.3.1 > >> > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 9:33 ` Bruce Richardson @ 2015-03-03 12:19 ` Marc Sune 2015-03-03 12:40 ` Panu Matilainen 0 siblings, 1 reply; 22+ messages in thread From: Marc Sune @ 2015-03-03 12:19 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev On 03/03/15 10:33, Bruce Richardson wrote: > On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: >> On 22/02/15 12:51, Marc Sune wrote: >>> I don't like the proposed patch, but I am recovering this old thread >>> because I agree on the problem statement. >>> >>> On 04/04/14 11:57, Ananyev, Konstantin wrote: >>>> Hi Cyril, >>>> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use >>>> to enable debug, or any other compiler/linker options you need. >>>> Wonder, why that is not enough? >>> EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why >>> setting individually: >>> >>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>> index 2f9643b..04adc0d 100644 >>> --- a/config/common_linuxapp >>> +++ b/config/common_linuxapp >>> @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y >>> # Compile generic ethernet library >>> # >>> CONFIG_RTE_LIBRTE_ETHER=y >>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n >>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y >>> >>> >>> to put an example, does not set -g and -O0 in that particular module only. >>> No one would ever use something compiled in DEBUG in production anyway. >>> >>> I always end up modifying manually Makefiles in the lib library that I am >>> interested in having insides, overriding CFLAGS=-O3, which is not that >>> nice. >> I would like some feedback on this idea. If the community sees benefit, I >> will work on a patch for this. >> >> Marc >> > So, your proposal is to patch things so that any time one sets DEBUG=y in the > build-time config for a library, we change the '-O3' to '-O0' and set -g also. > Correct? I am not sure what you mean by 'patch things'. I would simply enable the build system to override the default compilation flags (now DPDK-wide, or specifically librte_ wide) when _DEBUG=y for a library, changing compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I have to check if -O0 already implicitly means -fno-inline (even for __attribute__((always_inline)) ). I did a quick test. I chose KNI because it didn't have a DEBUG flag for the user-space library. For other libraries, the existing _DEBUG setting would be enough: marc@dpdk:~/dpdk$ git diff HEAD diff --git a/config/common_linuxapp b/config/common_linuxapp index 97f1c9e..8a3cef8 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y # CONFIG_RTE_LIBRTE_KNI=y CONFIG_RTE_KNI_PREEMPT_DEFAULT=y +CONFIG_RTE_LIBRTE_KNI_DEBUG=y CONFIG_RTE_KNI_KO_DEBUG=n CONFIG_RTE_KNI_VHOST=n CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile index 7107832..895f64e 100644 --- a/lib/librte_kni/Makefile +++ b/lib/librte_kni/Makefile @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # library name LIB = librte_kni.a -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) EXPORT_MAP := rte_kni_version.map diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 63a41e2..eee477d 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -78,6 +78,13 @@ endif ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) LDLIBS += -lrte_kni + +ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline +else +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing +endif + endif endif Thoughts? > > If that's the case, I see no harm in doing such a thing. I wonder how useful > the '-g' option would be, just limited to a single library, though. One would > suspect that it may be better applied globally, so that one can see the state > of the application as it makes the call into the library. It is IMHO. I am usually doing it this way, specially for ethdev initialization and the specific pmd (we probably need more fine grained return codes there). If you enable the debug for that library, you generally want to check the code and the state there, and you can access the input parameters of the function and the state of that library itself, which is generally enough, I think. Special cases are inline functions used by other libraries / user application, which are compiled either with the global DPDK flags (-O3) or by the user's application flags. Perhaps it also makes sense, in addition, to have a global "DEBUG" knob, which would enable to compile the entire DPDK library code with -O0 -g and possibly also with -fno-inline. This would also help debugging the inline functions. Marc > > /Bruce > >>> Marc >>> >>>> Thanks >>>> Konstantin >>>> >>>> -----Original Message----- >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Cyril Chemparathy >>>> Sent: Thursday, April 03, 2014 6:31 PM >>>> To: dev@dpdk.org >>>> Subject: [dpdk-dev] [PATCH] mk: add support for gdb debug info >>>> generation >>>> >>>> It is often useful to build with debug enabled, we add a config >>>> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. >>>> >>>> Note: This patch does not include corresponding changes for ICC. The >>>> author pleads abject ignorance in this regard, and welcomes >>>> recommendations. :-) >>>> >>>> Signed-off-by: Cyril Chemparathy <cchemparathy@tilera.com> >>>> --- >>>> config/defconfig_x86_64-default-linuxapp-gcc | 1 + >>>> mk/toolchain/gcc/rte.vars.mk | 5 +++++ >>>> 2 files changed, 6 insertions(+) >>>> >>>> diff --git a/config/defconfig_x86_64-default-linuxapp-gcc >>>> b/config/defconfig_x86_64-default-linuxapp-gcc >>>> index f11ffbf..3b36efd 100644 >>>> --- a/config/defconfig_x86_64-default-linuxapp-gcc >>>> +++ b/config/defconfig_x86_64-default-linuxapp-gcc >>>> @@ -67,6 +67,7 @@ CONFIG_RTE_ARCH_X86_64=y # CONFIG_RTE_TOOLCHAIN="gcc" >>>> CONFIG_RTE_TOOLCHAIN_GCC=y >>>> +CONFIG_RTE_TOOLCHAIN_DEBUG=n >>>> # >>>> # Use intrinsics or assembly code for key routines diff --git >>>> a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index >>>> 0edb93f..81ed3fa 100644 >>>> --- a/mk/toolchain/gcc/rte.vars.mk >>>> +++ b/mk/toolchain/gcc/rte.vars.mk >>>> @@ -68,6 +68,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif >>>> endif >>>> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) >>>> +TOOLCHAIN_CFLAGS += -g -ggdb >>>> +TOOLCHAIN_LDFLAGS += -g -ggdb >>>> +endif >>>> + >>>> WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes >>>> -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations >>>> -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align >>>> -Wnested-externs -Wcast-qual >>>> -- >>>> 1.8.3.1 >>>> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 12:19 ` Marc Sune @ 2015-03-03 12:40 ` Panu Matilainen 2015-03-03 12:56 ` Marc Sune 0 siblings, 1 reply; 22+ messages in thread From: Panu Matilainen @ 2015-03-03 12:40 UTC (permalink / raw) To: dev On 03/03/2015 02:19 PM, Marc Sune wrote: > > On 03/03/15 10:33, Bruce Richardson wrote: >> On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: >>> On 22/02/15 12:51, Marc Sune wrote: >>>> I don't like the proposed patch, but I am recovering this old thread >>>> because I agree on the problem statement. >>>> >>>> On 04/04/14 11:57, Ananyev, Konstantin wrote: >>>>> Hi Cyril, >>>>> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you can use >>>>> to enable debug, or any other compiler/linker options you need. >>>>> Wonder, why that is not enough? >>>> EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why >>>> setting individually: >>>> >>>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>>> index 2f9643b..04adc0d 100644 >>>> --- a/config/common_linuxapp >>>> +++ b/config/common_linuxapp >>>> @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y >>>> # Compile generic ethernet library >>>> # >>>> CONFIG_RTE_LIBRTE_ETHER=y >>>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n >>>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y >>>> >>>> >>>> to put an example, does not set -g and -O0 in that particular module >>>> only. >>>> No one would ever use something compiled in DEBUG in production anyway. >>>> >>>> I always end up modifying manually Makefiles in the lib library that >>>> I am >>>> interested in having insides, overriding CFLAGS=-O3, which is not that >>>> nice. >>> I would like some feedback on this idea. If the community sees >>> benefit, I >>> will work on a patch for this. >>> >>> Marc >>> >> So, your proposal is to patch things so that any time one sets DEBUG=y >> in the >> build-time config for a library, we change the '-O3' to '-O0' and set >> -g also. >> Correct? > > I am not sure what you mean by 'patch things'. I would simply enable the > build system to override the default compilation flags (now DPDK-wide, > or specifically librte_ wide) when _DEBUG=y for a library, changing > compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I > have to check if -O0 already implicitly means -fno-inline (even for > __attribute__((always_inline)) ). > > I did a quick test. I chose KNI because it didn't have a DEBUG flag for > the user-space library. For other libraries, the existing _DEBUG setting > would be enough: > > marc@dpdk:~/dpdk$ git diff HEAD > diff --git a/config/common_linuxapp b/config/common_linuxapp > index 97f1c9e..8a3cef8 100644 > --- a/config/common_linuxapp > +++ b/config/common_linuxapp > @@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y > # > CONFIG_RTE_LIBRTE_KNI=y > CONFIG_RTE_KNI_PREEMPT_DEFAULT=y > +CONFIG_RTE_LIBRTE_KNI_DEBUG=y > CONFIG_RTE_KNI_KO_DEBUG=n > CONFIG_RTE_KNI_VHOST=n > CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 > diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile > index 7107832..895f64e 100644 > --- a/lib/librte_kni/Makefile > +++ b/lib/librte_kni/Makefile > @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk > # library name > LIB = librte_kni.a > > -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing > +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) > > EXPORT_MAP := rte_kni_version.map > > diff --git a/mk/rte.app.mk b/mk/rte.app.mk > index 63a41e2..eee477d 100644 > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -78,6 +78,13 @@ endif > ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) > ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > LDLIBS += -lrte_kni > + > +ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) > +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline > +else > +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing > +endif > + > endif > endif > > > Thoughts? My 5c is that if anything, DPDK needs *less* places that muck around with compiler flags, not more. If you something like this for all the libraries in DPDK the number doesn't just increase a bit, it explodes. I dont see that much point in this thing, but I'd approach it by defining the debug flags someplace central, say DEBUG_FLAGS, and append that to the common cflags when *_DEBUG config is enabled. At least with gcc the last option wins so if you just append -O0 when debugging then that's what wins, the earlier -O3 does not matter. - Panu - - Panu - ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 12:40 ` Panu Matilainen @ 2015-03-03 12:56 ` Marc Sune 2015-03-03 13:03 ` Bruce Richardson 0 siblings, 1 reply; 22+ messages in thread From: Marc Sune @ 2015-03-03 12:56 UTC (permalink / raw) To: dev On 03/03/15 13:40, Panu Matilainen wrote: > On 03/03/2015 02:19 PM, Marc Sune wrote: >> >> On 03/03/15 10:33, Bruce Richardson wrote: >>> On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: >>>> On 22/02/15 12:51, Marc Sune wrote: >>>>> I don't like the proposed patch, but I am recovering this old thread >>>>> because I agree on the problem statement. >>>>> >>>>> On 04/04/14 11:57, Ananyev, Konstantin wrote: >>>>>> Hi Cyril, >>>>>> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you >>>>>> can use >>>>>> to enable debug, or any other compiler/linker options you need. >>>>>> Wonder, why that is not enough? >>>>> EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why >>>>> setting individually: >>>>> >>>>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>>>> index 2f9643b..04adc0d 100644 >>>>> --- a/config/common_linuxapp >>>>> +++ b/config/common_linuxapp >>>>> @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y >>>>> # Compile generic ethernet library >>>>> # >>>>> CONFIG_RTE_LIBRTE_ETHER=y >>>>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n >>>>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y >>>>> >>>>> >>>>> to put an example, does not set -g and -O0 in that particular module >>>>> only. >>>>> No one would ever use something compiled in DEBUG in production >>>>> anyway. >>>>> >>>>> I always end up modifying manually Makefiles in the lib library that >>>>> I am >>>>> interested in having insides, overriding CFLAGS=-O3, which is not >>>>> that >>>>> nice. >>>> I would like some feedback on this idea. If the community sees >>>> benefit, I >>>> will work on a patch for this. >>>> >>>> Marc >>>> >>> So, your proposal is to patch things so that any time one sets DEBUG=y >>> in the >>> build-time config for a library, we change the '-O3' to '-O0' and set >>> -g also. >>> Correct? >> >> I am not sure what you mean by 'patch things'. I would simply enable the >> build system to override the default compilation flags (now DPDK-wide, >> or specifically librte_ wide) when _DEBUG=y for a library, changing >> compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I >> have to check if -O0 already implicitly means -fno-inline (even for >> __attribute__((always_inline)) ). >> >> I did a quick test. I chose KNI because it didn't have a DEBUG flag for >> the user-space library. For other libraries, the existing _DEBUG setting >> would be enough: >> >> marc@dpdk:~/dpdk$ git diff HEAD >> diff --git a/config/common_linuxapp b/config/common_linuxapp >> index 97f1c9e..8a3cef8 100644 >> --- a/config/common_linuxapp >> +++ b/config/common_linuxapp >> @@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y >> # >> CONFIG_RTE_LIBRTE_KNI=y >> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y >> +CONFIG_RTE_LIBRTE_KNI_DEBUG=y >> CONFIG_RTE_KNI_KO_DEBUG=n >> CONFIG_RTE_KNI_VHOST=n >> CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 >> diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile >> index 7107832..895f64e 100644 >> --- a/lib/librte_kni/Makefile >> +++ b/lib/librte_kni/Makefile >> @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk >> # library name >> LIB = librte_kni.a >> >> -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing >> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) >> >> EXPORT_MAP := rte_kni_version.map >> >> diff --git a/mk/rte.app.mk b/mk/rte.app.mk >> index 63a41e2..eee477d 100644 >> --- a/mk/rte.app.mk >> +++ b/mk/rte.app.mk >> @@ -78,6 +78,13 @@ endif >> ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) >> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >> LDLIBS += -lrte_kni >> + >> +ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) >> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline >> +else >> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing >> +endif >> + >> endif >> endif >> >> >> Thoughts? > > My 5c is that if anything, DPDK needs *less* places that muck around > with compiler flags, not more. If you something like this for all the > libraries in DPDK the number doesn't just increase a bit, it explodes. If you check the part below this one in my original email, that you stripped out (without notice), the suggestion was also to add a global _DEBUG parameter for the entire DPDK set of libraries, to change all the CFLAGS at once (not in the attached PATCH). > > I dont see that much point in this thing, but I'd approach it by > defining the debug flags someplace central, say DEBUG_FLAGS, and > append that to the common cflags when *_DEBUG config is enabled. At > least with gcc the last option wins so if you just append -O0 when > debugging then that's what wins, the earlier -O3 does not matter. The original problem is the one you expose; libraries hardcode the CFLAGS, ignoring user-flags. There is no way to change this unless you change the Makefiles directly. But right now, each library does hardcode its *own* flags (check Makefiles for the libraries), so there is already not a unified approach here. I see for instance KNI having -fno-strict-aliasing while other libraries don't. Having said that, there are moments, specially with -O3, in which to be able to reproduce a bug, you need to compile certain parts of code with -O3 and the rest with -O0 -g (the ones to be debugged). The approach proposed (both a global *and* a lib specific) allows that. Marc > > - Panu - > > - Panu - > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 12:56 ` Marc Sune @ 2015-03-03 13:03 ` Bruce Richardson 2015-03-03 13:27 ` Marc Sune ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Bruce Richardson @ 2015-03-03 13:03 UTC (permalink / raw) To: Marc Sune; +Cc: dev On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: > > On 03/03/15 13:40, Panu Matilainen wrote: > >On 03/03/2015 02:19 PM, Marc Sune wrote: > >> > >>On 03/03/15 10:33, Bruce Richardson wrote: > >>>On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: > >>>>On 22/02/15 12:51, Marc Sune wrote: > >>>>>I don't like the proposed patch, but I am recovering this old thread > >>>>>because I agree on the problem statement. > >>>>> > >>>>>On 04/04/14 11:57, Ananyev, Konstantin wrote: > >>>>>>Hi Cyril, > >>>>>>We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you > >>>>>>can use > >>>>>>to enable debug, or any other compiler/linker options you need. > >>>>>>Wonder, why that is not enough? > >>>>>EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why > >>>>>setting individually: > >>>>> > >>>>>diff --git a/config/common_linuxapp b/config/common_linuxapp > >>>>>index 2f9643b..04adc0d 100644 > >>>>>--- a/config/common_linuxapp > >>>>>+++ b/config/common_linuxapp > >>>>>@@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y > >>>>># Compile generic ethernet library > >>>>># > >>>>>CONFIG_RTE_LIBRTE_ETHER=y > >>>>>-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n > >>>>>+CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y > >>>>> > >>>>> > >>>>>to put an example, does not set -g and -O0 in that particular module > >>>>>only. > >>>>>No one would ever use something compiled in DEBUG in production > >>>>>anyway. > >>>>> > >>>>>I always end up modifying manually Makefiles in the lib library that > >>>>>I am > >>>>>interested in having insides, overriding CFLAGS=-O3, which is not > >>>>>that > >>>>>nice. > >>>>I would like some feedback on this idea. If the community sees > >>>>benefit, I > >>>>will work on a patch for this. > >>>> > >>>>Marc > >>>> > >>>So, your proposal is to patch things so that any time one sets DEBUG=y > >>>in the > >>>build-time config for a library, we change the '-O3' to '-O0' and set > >>>-g also. > >>>Correct? > >> > >>I am not sure what you mean by 'patch things'. I would simply enable the > >>build system to override the default compilation flags (now DPDK-wide, > >>or specifically librte_ wide) when _DEBUG=y for a library, changing > >>compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I > >>have to check if -O0 already implicitly means -fno-inline (even for > >>__attribute__((always_inline)) ). > >> > >>I did a quick test. I chose KNI because it didn't have a DEBUG flag for > >>the user-space library. For other libraries, the existing _DEBUG setting > >>would be enough: > >> > >>marc@dpdk:~/dpdk$ git diff HEAD > >>diff --git a/config/common_linuxapp b/config/common_linuxapp > >>index 97f1c9e..8a3cef8 100644 > >>--- a/config/common_linuxapp > >>+++ b/config/common_linuxapp > >>@@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y > >> # > >> CONFIG_RTE_LIBRTE_KNI=y > >> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y > >>+CONFIG_RTE_LIBRTE_KNI_DEBUG=y > >> CONFIG_RTE_KNI_KO_DEBUG=n > >> CONFIG_RTE_KNI_VHOST=n > >> CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 > >>diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile > >>index 7107832..895f64e 100644 > >>--- a/lib/librte_kni/Makefile > >>+++ b/lib/librte_kni/Makefile > >>@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk > >> # library name > >> LIB = librte_kni.a > >> > >>-CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing > >>+CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) > >> > >> EXPORT_MAP := rte_kni_version.map > >> > >>diff --git a/mk/rte.app.mk b/mk/rte.app.mk > >>index 63a41e2..eee477d 100644 > >>--- a/mk/rte.app.mk > >>+++ b/mk/rte.app.mk > >>@@ -78,6 +78,13 @@ endif > >> ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) > >> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > >> LDLIBS += -lrte_kni > >>+ > >>+ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) > >>+CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline > >>+else > >>+CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing > >>+endif > >>+ > >> endif > >> endif > >> > >> > >>Thoughts? > > > >My 5c is that if anything, DPDK needs *less* places that muck around with > >compiler flags, not more. If you something like this for all the libraries > >in DPDK the number doesn't just increase a bit, it explodes. > > If you check the part below this one in my original email, that you stripped > out (without notice), the suggestion was also to add a global _DEBUG > parameter for the entire DPDK set of libraries, to change all the CFLAGS at > once (not in the attached PATCH). > > > > >I dont see that much point in this thing, but I'd approach it by defining > >the debug flags someplace central, say DEBUG_FLAGS, and append that to the > >common cflags when *_DEBUG config is enabled. At least with gcc the last > >option wins so if you just append -O0 when debugging then that's what > >wins, the earlier -O3 does not matter. > > The original problem is the one you expose; libraries hardcode the CFLAGS, > ignoring user-flags. There is no way to change this unless you change the > Makefiles directly. > > But right now, each library does hardcode its *own* flags (check Makefiles > for the libraries), so there is already not a unified approach here. I see > for instance KNI having -fno-strict-aliasing while other libraries don't. > > Having said that, there are moments, specially with -O3, in which to be able > to reproduce a bug, you need to compile certain parts of code with -O3 and > the rest with -O0 -g (the ones to be debugged). The approach proposed (both > a global *and* a lib specific) allows that. > > Marc > I believe that the global option of overriding the CFLAGS is already sufficiently covered - including being documented in programmers guide - by EXTRA_CFLAGS. The ability to turn off optimization support for a single library is not covered anywhere, and that suggestion seems reasonable to me. For each library, we can just append '-O0 -g' to the CFLAGS in that libraries makefile if the debug option is set. I don't see that as significantly complicating things [though I wouldn't make any changes to the rte.app.mk to allow this, just have it per lib in the lib's makefile] /Bruce > > - Panu - > > > > - Panu - > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 13:03 ` Bruce Richardson @ 2015-03-03 13:27 ` Marc Sune 2015-03-04 9:44 ` Olivier MATZ 2015-03-03 13:31 ` Ananyev, Konstantin 2015-03-03 13:32 ` Thomas Monjalon 2 siblings, 1 reply; 22+ messages in thread From: Marc Sune @ 2015-03-03 13:27 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev On 03/03/15 14:03, Bruce Richardson wrote: > On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: >> On 03/03/15 13:40, Panu Matilainen wrote: >>> On 03/03/2015 02:19 PM, Marc Sune wrote: >>>> On 03/03/15 10:33, Bruce Richardson wrote: >>>>> On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: >>>>>> On 22/02/15 12:51, Marc Sune wrote: >>>>>>> I don't like the proposed patch, but I am recovering this old thread >>>>>>> because I agree on the problem statement. >>>>>>> >>>>>>> On 04/04/14 11:57, Ananyev, Konstantin wrote: >>>>>>>> Hi Cyril, >>>>>>>> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you >>>>>>>> can use >>>>>>>> to enable debug, or any other compiler/linker options you need. >>>>>>>> Wonder, why that is not enough? >>>>>>> EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why >>>>>>> setting individually: >>>>>>> >>>>>>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>>>>>> index 2f9643b..04adc0d 100644 >>>>>>> --- a/config/common_linuxapp >>>>>>> +++ b/config/common_linuxapp >>>>>>> @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y >>>>>>> # Compile generic ethernet library >>>>>>> # >>>>>>> CONFIG_RTE_LIBRTE_ETHER=y >>>>>>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n >>>>>>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y >>>>>>> >>>>>>> >>>>>>> to put an example, does not set -g and -O0 in that particular module >>>>>>> only. >>>>>>> No one would ever use something compiled in DEBUG in production >>>>>>> anyway. >>>>>>> >>>>>>> I always end up modifying manually Makefiles in the lib library that >>>>>>> I am >>>>>>> interested in having insides, overriding CFLAGS=-O3, which is not >>>>>>> that >>>>>>> nice. >>>>>> I would like some feedback on this idea. If the community sees >>>>>> benefit, I >>>>>> will work on a patch for this. >>>>>> >>>>>> Marc >>>>>> >>>>> So, your proposal is to patch things so that any time one sets DEBUG=y >>>>> in the >>>>> build-time config for a library, we change the '-O3' to '-O0' and set >>>>> -g also. >>>>> Correct? >>>> I am not sure what you mean by 'patch things'. I would simply enable the >>>> build system to override the default compilation flags (now DPDK-wide, >>>> or specifically librte_ wide) when _DEBUG=y for a library, changing >>>> compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I >>>> have to check if -O0 already implicitly means -fno-inline (even for >>>> __attribute__((always_inline)) ). >>>> >>>> I did a quick test. I chose KNI because it didn't have a DEBUG flag for >>>> the user-space library. For other libraries, the existing _DEBUG setting >>>> would be enough: >>>> >>>> marc@dpdk:~/dpdk$ git diff HEAD >>>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>>> index 97f1c9e..8a3cef8 100644 >>>> --- a/config/common_linuxapp >>>> +++ b/config/common_linuxapp >>>> @@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y >>>> # >>>> CONFIG_RTE_LIBRTE_KNI=y >>>> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y >>>> +CONFIG_RTE_LIBRTE_KNI_DEBUG=y >>>> CONFIG_RTE_KNI_KO_DEBUG=n >>>> CONFIG_RTE_KNI_VHOST=n >>>> CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 >>>> diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile >>>> index 7107832..895f64e 100644 >>>> --- a/lib/librte_kni/Makefile >>>> +++ b/lib/librte_kni/Makefile >>>> @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk >>>> # library name >>>> LIB = librte_kni.a >>>> >>>> -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing >>>> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) >>>> >>>> EXPORT_MAP := rte_kni_version.map >>>> >>>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk >>>> index 63a41e2..eee477d 100644 >>>> --- a/mk/rte.app.mk >>>> +++ b/mk/rte.app.mk >>>> @@ -78,6 +78,13 @@ endif >>>> ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) >>>> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >>>> LDLIBS += -lrte_kni >>>> + >>>> +ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) >>>> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline >>>> +else >>>> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing >>>> +endif >>>> + >>>> endif >>>> endif >>>> >>>> >>>> Thoughts? >>> My 5c is that if anything, DPDK needs *less* places that muck around with >>> compiler flags, not more. If you something like this for all the libraries >>> in DPDK the number doesn't just increase a bit, it explodes. >> If you check the part below this one in my original email, that you stripped >> out (without notice), the suggestion was also to add a global _DEBUG >> parameter for the entire DPDK set of libraries, to change all the CFLAGS at >> once (not in the attached PATCH). >> >>> I dont see that much point in this thing, but I'd approach it by defining >>> the debug flags someplace central, say DEBUG_FLAGS, and append that to the >>> common cflags when *_DEBUG config is enabled. At least with gcc the last >>> option wins so if you just append -O0 when debugging then that's what >>> wins, the earlier -O3 does not matter. >> The original problem is the one you expose; libraries hardcode the CFLAGS, >> ignoring user-flags. There is no way to change this unless you change the >> Makefiles directly. >> >> But right now, each library does hardcode its *own* flags (check Makefiles >> for the libraries), so there is already not a unified approach here. I see >> for instance KNI having -fno-strict-aliasing while other libraries don't. >> >> Having said that, there are moments, specially with -O3, in which to be able >> to reproduce a bug, you need to compile certain parts of code with -O3 and >> the rest with -O0 -g (the ones to be debugged). The approach proposed (both >> a global *and* a lib specific) allows that. >> >> Marc >> > I believe that the global option of overriding the CFLAGS is already sufficiently > covered - including being documented in programmers guide - by EXTRA_CFLAGS. To be honest, I tried EXTRA_CFLAGS at some point in time (probably 1.5 or 1.6, but maybe not stable releases) and it did not work, so I ended up doing it manually, and never tried again. It does work now with CFLAGS, I didn't try LDFLAGS, but it does not for EXTRA_CPPFLAGS apparently (unless I made some stupid mistake): marc@dpdk:~/dpdk$ git diff diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c index 4e70fa0..4a1e538 100644 --- a/lib/librte_kni/rte_kni.c +++ b/lib/librte_kni/rte_kni.c @@ -61,6 +61,10 @@ #define KNI_MEM_CHECK(cond) do { if (cond) goto kni_fail; } while (0) +#ifdef TEST_CPPFLAGS + #error TEST_CPPFLAGS defined +#endif + /** * KNI context */ marc@dpdk:~/dpdk$ export EXTRA_CPPFLAGS='-DTEST_CPPFLAGS' marc@dpdk:~/dpdk$ make install T=x86_64-native-linuxapp-gcc ... Build complete marc@dpdk:~/dpdk$ > The > ability to turn off optimization support for a single library is not covered > anywhere, and that suggestion seems reasonable to me. For each library, we can > just append '-O0 -g' to the CFLAGS in that libraries makefile if the debug option > is set. I don't see that as significantly complicating things [though I wouldn't > make any changes to the rte.app.mk to allow this, just have it per lib in the > lib's makefile] Right. It makes more sense there. Marc > > /Bruce > >>> - Panu - >>> >>> - Panu - >>> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 13:27 ` Marc Sune @ 2015-03-04 9:44 ` Olivier MATZ 0 siblings, 0 replies; 22+ messages in thread From: Olivier MATZ @ 2015-03-04 9:44 UTC (permalink / raw) To: Marc Sune, Bruce Richardson; +Cc: dev Hi Marc, On 03/03/2015 02:27 PM, Marc Sune wrote: > > On 03/03/15 14:03, Bruce Richardson wrote: >> On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: >> [...] >> I believe that the global option of overriding the CFLAGS is already >> sufficiently >> covered - including being documented in programmers guide - by >> EXTRA_CFLAGS. > > To be honest, I tried EXTRA_CFLAGS at some point in time (probably 1.5 > or 1.6, but maybe not stable releases) and it did not work, so I ended > up doing it manually, and never tried again. > > It does work now with CFLAGS, I didn't try LDFLAGS, but it does not for > EXTRA_CPPFLAGS apparently (unless I made some stupid mistake): > > marc@dpdk:~/dpdk$ git diff > diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c > index 4e70fa0..4a1e538 100644 > --- a/lib/librte_kni/rte_kni.c > +++ b/lib/librte_kni/rte_kni.c > @@ -61,6 +61,10 @@ > > #define KNI_MEM_CHECK(cond) do { if (cond) goto kni_fail; } while (0) > > +#ifdef TEST_CPPFLAGS > + #error TEST_CPPFLAGS defined > +#endif > + > /** > * KNI context > */ > > marc@dpdk:~/dpdk$ export EXTRA_CPPFLAGS='-DTEST_CPPFLAGS' > marc@dpdk:~/dpdk$ make install T=x86_64-native-linuxapp-gcc > ... > Build complete The reason why it does not work is described in the documentation: ./doc/guides/prog_guide/build_app.rst:* CPPFLAGS: The flags to use to provide flags to the C preprocessor (only useful when assembling .S files) ./doc/guides/prog_guide/dev_kit_build_system.rst:* CPPFLAGS: Flags to use to give flags to C preprocessor (only useful when assembling .S files). ./doc/guides/prog_guide/dev_kit_build_system.rst:* EXTRA_CPPFLAGS: The content of this variable is appended after CPPFLAGS when using a C preprocessor on assembly files. I think your test would work with EXTRA_CFLAGS. I don't say it's the proper behavior, but at least it's coherent with the documentation. Regards, Olivier ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 13:03 ` Bruce Richardson 2015-03-03 13:27 ` Marc Sune @ 2015-03-03 13:31 ` Ananyev, Konstantin 2015-03-03 14:39 ` Marc Sune 2015-03-03 13:32 ` Thomas Monjalon 2 siblings, 1 reply; 22+ messages in thread From: Ananyev, Konstantin @ 2015-03-03 13:31 UTC (permalink / raw) To: Richardson, Bruce, Marc Sune; +Cc: dev > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Tuesday, March 03, 2015 1:03 PM > To: Marc Sune > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation > > On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: > > > > On 03/03/15 13:40, Panu Matilainen wrote: > > >On 03/03/2015 02:19 PM, Marc Sune wrote: > > >> > > >>On 03/03/15 10:33, Bruce Richardson wrote: > > >>>On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: > > >>>>On 22/02/15 12:51, Marc Sune wrote: > > >>>>>I don't like the proposed patch, but I am recovering this old thread > > >>>>>because I agree on the problem statement. > > >>>>> > > >>>>>On 04/04/14 11:57, Ananyev, Konstantin wrote: > > >>>>>>Hi Cyril, > > >>>>>>We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you > > >>>>>>can use > > >>>>>>to enable debug, or any other compiler/linker options you need. > > >>>>>>Wonder, why that is not enough? > > >>>>>EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why > > >>>>>setting individually: > > >>>>> > > >>>>>diff --git a/config/common_linuxapp b/config/common_linuxapp > > >>>>>index 2f9643b..04adc0d 100644 > > >>>>>--- a/config/common_linuxapp > > >>>>>+++ b/config/common_linuxapp > > >>>>>@@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y > > >>>>># Compile generic ethernet library > > >>>>># > > >>>>>CONFIG_RTE_LIBRTE_ETHER=y > > >>>>>-CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n > > >>>>>+CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y > > >>>>> > > >>>>> > > >>>>>to put an example, does not set -g and -O0 in that particular module > > >>>>>only. > > >>>>>No one would ever use something compiled in DEBUG in production > > >>>>>anyway. > > >>>>> > > >>>>>I always end up modifying manually Makefiles in the lib library that > > >>>>>I am > > >>>>>interested in having insides, overriding CFLAGS=-O3, which is not > > >>>>>that > > >>>>>nice. > > >>>>I would like some feedback on this idea. If the community sees > > >>>>benefit, I > > >>>>will work on a patch for this. > > >>>> > > >>>>Marc > > >>>> > > >>>So, your proposal is to patch things so that any time one sets DEBUG=y > > >>>in the > > >>>build-time config for a library, we change the '-O3' to '-O0' and set > > >>>-g also. > > >>>Correct? > > >> > > >>I am not sure what you mean by 'patch things'. I would simply enable the > > >>build system to override the default compilation flags (now DPDK-wide, > > >>or specifically librte_ wide) when _DEBUG=y for a library, changing > > >>compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I > > >>have to check if -O0 already implicitly means -fno-inline (even for > > >>__attribute__((always_inline)) ). > > >> > > >>I did a quick test. I chose KNI because it didn't have a DEBUG flag for > > >>the user-space library. For other libraries, the existing _DEBUG setting > > >>would be enough: > > >> > > >>marc@dpdk:~/dpdk$ git diff HEAD > > >>diff --git a/config/common_linuxapp b/config/common_linuxapp > > >>index 97f1c9e..8a3cef8 100644 > > >>--- a/config/common_linuxapp > > >>+++ b/config/common_linuxapp > > >>@@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y > > >> # > > >> CONFIG_RTE_LIBRTE_KNI=y > > >> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y > > >>+CONFIG_RTE_LIBRTE_KNI_DEBUG=y > > >> CONFIG_RTE_KNI_KO_DEBUG=n > > >> CONFIG_RTE_KNI_VHOST=n > > >> CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 > > >>diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile > > >>index 7107832..895f64e 100644 > > >>--- a/lib/librte_kni/Makefile > > >>+++ b/lib/librte_kni/Makefile > > >>@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk > > >> # library name > > >> LIB = librte_kni.a > > >> > > >>-CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing > > >>+CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) > > >> > > >> EXPORT_MAP := rte_kni_version.map > > >> > > >>diff --git a/mk/rte.app.mk b/mk/rte.app.mk > > >>index 63a41e2..eee477d 100644 > > >>--- a/mk/rte.app.mk > > >>+++ b/mk/rte.app.mk > > >>@@ -78,6 +78,13 @@ endif > > >> ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) > > >> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > > >> LDLIBS += -lrte_kni > > >>+ > > >>+ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) > > >>+CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline > > >>+else > > >>+CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing > > >>+endif > > >>+ > > >> endif > > >> endif > > >> > > >> > > >>Thoughts? > > > > > >My 5c is that if anything, DPDK needs *less* places that muck around with > > >compiler flags, not more. If you something like this for all the libraries > > >in DPDK the number doesn't just increase a bit, it explodes. > > > > If you check the part below this one in my original email, that you stripped > > out (without notice), the suggestion was also to add a global _DEBUG > > parameter for the entire DPDK set of libraries, to change all the CFLAGS at > > once (not in the attached PATCH). > > > > > > > >I dont see that much point in this thing, but I'd approach it by defining > > >the debug flags someplace central, say DEBUG_FLAGS, and append that to the > > >common cflags when *_DEBUG config is enabled. At least with gcc the last > > >option wins so if you just append -O0 when debugging then that's what > > >wins, the earlier -O3 does not matter. > > > > The original problem is the one you expose; libraries hardcode the CFLAGS, > > ignoring user-flags. There is no way to change this unless you change the > > Makefiles directly. > > > > But right now, each library does hardcode its *own* flags (check Makefiles > > for the libraries), so there is already not a unified approach here. I see > > for instance KNI having -fno-strict-aliasing while other libraries don't. > > > > Having said that, there are moments, specially with -O3, in which to be able > > to reproduce a bug, you need to compile certain parts of code with -O3 and > > the rest with -O0 -g (the ones to be debugged). The approach proposed (both > > a global *and* a lib specific) allows that. > > > > Marc > > > > I believe that the global option of overriding the CFLAGS is already sufficiently > covered - including being documented in programmers guide - by EXTRA_CFLAGS. The > ability to turn off optimization support for a single library is not covered > anywhere, and that suggestion seems reasonable to me. For each library, we can > just append '-O0 -g' to the CFLAGS in that libraries makefile if the debug option > is set. I don't see that as significantly complicating things [though I wouldn't > make any changes to the rte.app.mk to allow this, just have it per lib in the > lib's makefile] > Well, but then people would say 'why only -g -O0' for _DEBUG config option? And would ask for ability to add/change other compile options to add/change for particular library. If we need that, probably we can introduce RTE_LIBRTE_<LIBNAME>_EXTRA_CFLAGS config macros for each library? So people can set them in their config files to whatever they like? Konstantin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 13:31 ` Ananyev, Konstantin @ 2015-03-03 14:39 ` Marc Sune 2015-03-03 16:24 ` Ananyev, Konstantin 0 siblings, 1 reply; 22+ messages in thread From: Marc Sune @ 2015-03-03 14:39 UTC (permalink / raw) To: Ananyev, Konstantin, Richardson, Bruce; +Cc: dev On 03/03/15 14:31, Ananyev, Konstantin wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson >> Sent: Tuesday, March 03, 2015 1:03 PM >> To: Marc Sune >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation >> >> On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: >>> On 03/03/15 13:40, Panu Matilainen wrote: >>>> On 03/03/2015 02:19 PM, Marc Sune wrote: >>>>> On 03/03/15 10:33, Bruce Richardson wrote: >>>>>> On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: >>>>>>> On 22/02/15 12:51, Marc Sune wrote: >>>>>>>> I don't like the proposed patch, but I am recovering this old thread >>>>>>>> because I agree on the problem statement. >>>>>>>> >>>>>>>> On 04/04/14 11:57, Ananyev, Konstantin wrote: >>>>>>>>> Hi Cyril, >>>>>>>>> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you >>>>>>>>> can use >>>>>>>>> to enable debug, or any other compiler/linker options you need. >>>>>>>>> Wonder, why that is not enough? >>>>>>>> EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why >>>>>>>> setting individually: >>>>>>>> >>>>>>>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>>>>>>> index 2f9643b..04adc0d 100644 >>>>>>>> --- a/config/common_linuxapp >>>>>>>> +++ b/config/common_linuxapp >>>>>>>> @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y >>>>>>>> # Compile generic ethernet library >>>>>>>> # >>>>>>>> CONFIG_RTE_LIBRTE_ETHER=y >>>>>>>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n >>>>>>>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y >>>>>>>> >>>>>>>> >>>>>>>> to put an example, does not set -g and -O0 in that particular module >>>>>>>> only. >>>>>>>> No one would ever use something compiled in DEBUG in production >>>>>>>> anyway. >>>>>>>> >>>>>>>> I always end up modifying manually Makefiles in the lib library that >>>>>>>> I am >>>>>>>> interested in having insides, overriding CFLAGS=-O3, which is not >>>>>>>> that >>>>>>>> nice. >>>>>>> I would like some feedback on this idea. If the community sees >>>>>>> benefit, I >>>>>>> will work on a patch for this. >>>>>>> >>>>>>> Marc >>>>>>> >>>>>> So, your proposal is to patch things so that any time one sets DEBUG=y >>>>>> in the >>>>>> build-time config for a library, we change the '-O3' to '-O0' and set >>>>>> -g also. >>>>>> Correct? >>>>> I am not sure what you mean by 'patch things'. I would simply enable the >>>>> build system to override the default compilation flags (now DPDK-wide, >>>>> or specifically librte_ wide) when _DEBUG=y for a library, changing >>>>> compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I >>>>> have to check if -O0 already implicitly means -fno-inline (even for >>>>> __attribute__((always_inline)) ). >>>>> >>>>> I did a quick test. I chose KNI because it didn't have a DEBUG flag for >>>>> the user-space library. For other libraries, the existing _DEBUG setting >>>>> would be enough: >>>>> >>>>> marc@dpdk:~/dpdk$ git diff HEAD >>>>> diff --git a/config/common_linuxapp b/config/common_linuxapp >>>>> index 97f1c9e..8a3cef8 100644 >>>>> --- a/config/common_linuxapp >>>>> +++ b/config/common_linuxapp >>>>> @@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y >>>>> # >>>>> CONFIG_RTE_LIBRTE_KNI=y >>>>> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y >>>>> +CONFIG_RTE_LIBRTE_KNI_DEBUG=y >>>>> CONFIG_RTE_KNI_KO_DEBUG=n >>>>> CONFIG_RTE_KNI_VHOST=n >>>>> CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 >>>>> diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile >>>>> index 7107832..895f64e 100644 >>>>> --- a/lib/librte_kni/Makefile >>>>> +++ b/lib/librte_kni/Makefile >>>>> @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk >>>>> # library name >>>>> LIB = librte_kni.a >>>>> >>>>> -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing >>>>> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) >>>>> >>>>> EXPORT_MAP := rte_kni_version.map >>>>> >>>>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk >>>>> index 63a41e2..eee477d 100644 >>>>> --- a/mk/rte.app.mk >>>>> +++ b/mk/rte.app.mk >>>>> @@ -78,6 +78,13 @@ endif >>>>> ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) >>>>> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >>>>> LDLIBS += -lrte_kni >>>>> + >>>>> +ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) >>>>> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline >>>>> +else >>>>> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing >>>>> +endif >>>>> + >>>>> endif >>>>> endif >>>>> >>>>> >>>>> Thoughts? >>>> My 5c is that if anything, DPDK needs *less* places that muck around with >>>> compiler flags, not more. If you something like this for all the libraries >>>> in DPDK the number doesn't just increase a bit, it explodes. >>> If you check the part below this one in my original email, that you stripped >>> out (without notice), the suggestion was also to add a global _DEBUG >>> parameter for the entire DPDK set of libraries, to change all the CFLAGS at >>> once (not in the attached PATCH). >>> >>>> I dont see that much point in this thing, but I'd approach it by defining >>>> the debug flags someplace central, say DEBUG_FLAGS, and append that to the >>>> common cflags when *_DEBUG config is enabled. At least with gcc the last >>>> option wins so if you just append -O0 when debugging then that's what >>>> wins, the earlier -O3 does not matter. >>> The original problem is the one you expose; libraries hardcode the CFLAGS, >>> ignoring user-flags. There is no way to change this unless you change the >>> Makefiles directly. >>> >>> But right now, each library does hardcode its *own* flags (check Makefiles >>> for the libraries), so there is already not a unified approach here. I see >>> for instance KNI having -fno-strict-aliasing while other libraries don't. >>> >>> Having said that, there are moments, specially with -O3, in which to be able >>> to reproduce a bug, you need to compile certain parts of code with -O3 and >>> the rest with -O0 -g (the ones to be debugged). The approach proposed (both >>> a global *and* a lib specific) allows that. >>> >>> Marc >>> >> I believe that the global option of overriding the CFLAGS is already sufficiently >> covered - including being documented in programmers guide - by EXTRA_CFLAGS. The >> ability to turn off optimization support for a single library is not covered >> anywhere, and that suggestion seems reasonable to me. For each library, we can >> just append '-O0 -g' to the CFLAGS in that libraries makefile if the debug option >> is set. I don't see that as significantly complicating things [though I wouldn't >> make any changes to the rte.app.mk to allow this, just have it per lib in the >> lib's makefile] >> > Well, but then people would say 'why only -g -O0' for _DEBUG config option? > And would ask for ability to add/change other compile options to add/change for particular library. > If we need that, probably we can introduce RTE_LIBRTE_<LIBNAME>_EXTRA_CFLAGS config macros for each library? > So people can set them in their config files to whatever they like? It is not a bad idea either. However, there are already those _DEBUG config elements (the KNI is a special case). Maybe both can be combined (i.e. RTE_LIBRTE_<LIBNAME>_EXTRA_CFLAGS should always override _DEBUG). It would probably get a bit over-engineered then, though. marc > > Konstantin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 14:39 ` Marc Sune @ 2015-03-03 16:24 ` Ananyev, Konstantin 0 siblings, 0 replies; 22+ messages in thread From: Ananyev, Konstantin @ 2015-03-03 16:24 UTC (permalink / raw) To: Marc Sune, Richardson, Bruce; +Cc: dev > -----Original Message----- > From: Marc Sune [mailto:marc.sune@bisdn.de] > Sent: Tuesday, March 03, 2015 2:39 PM > To: Ananyev, Konstantin; Richardson, Bruce > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation > > > On 03/03/15 14:31, Ananyev, Konstantin wrote: > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > >> Sent: Tuesday, March 03, 2015 1:03 PM > >> To: Marc Sune > >> Cc: dev@dpdk.org > >> Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation > >> > >> On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: > >>> On 03/03/15 13:40, Panu Matilainen wrote: > >>>> On 03/03/2015 02:19 PM, Marc Sune wrote: > >>>>> On 03/03/15 10:33, Bruce Richardson wrote: > >>>>>> On Mon, Mar 02, 2015 at 06:32:13PM +0100, Marc Sune wrote: > >>>>>>> On 22/02/15 12:51, Marc Sune wrote: > >>>>>>>> I don't like the proposed patch, but I am recovering this old thread > >>>>>>>> because I agree on the problem statement. > >>>>>>>> > >>>>>>>> On 04/04/14 11:57, Ananyev, Konstantin wrote: > >>>>>>>>> Hi Cyril, > >>>>>>>>> We already do have 'EXTRA_CFLAGS' and 'EXTRA_LDFLAGS' that you > >>>>>>>>> can use > >>>>>>>>> to enable debug, or any other compiler/linker options you need. > >>>>>>>>> Wonder, why that is not enough? > >>>>>>>> EXTRA_FLAGS var affects all the DPDK libraries. I was wondering why > >>>>>>>> setting individually: > >>>>>>>> > >>>>>>>> diff --git a/config/common_linuxapp b/config/common_linuxapp > >>>>>>>> index 2f9643b..04adc0d 100644 > >>>>>>>> --- a/config/common_linuxapp > >>>>>>>> +++ b/config/common_linuxapp > >>>>>>>> @@ -127,7 +127,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y > >>>>>>>> # Compile generic ethernet library > >>>>>>>> # > >>>>>>>> CONFIG_RTE_LIBRTE_ETHER=y > >>>>>>>> -CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n > >>>>>>>> +CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y > >>>>>>>> > >>>>>>>> > >>>>>>>> to put an example, does not set -g and -O0 in that particular module > >>>>>>>> only. > >>>>>>>> No one would ever use something compiled in DEBUG in production > >>>>>>>> anyway. > >>>>>>>> > >>>>>>>> I always end up modifying manually Makefiles in the lib library that > >>>>>>>> I am > >>>>>>>> interested in having insides, overriding CFLAGS=-O3, which is not > >>>>>>>> that > >>>>>>>> nice. > >>>>>>> I would like some feedback on this idea. If the community sees > >>>>>>> benefit, I > >>>>>>> will work on a patch for this. > >>>>>>> > >>>>>>> Marc > >>>>>>> > >>>>>> So, your proposal is to patch things so that any time one sets DEBUG=y > >>>>>> in the > >>>>>> build-time config for a library, we change the '-O3' to '-O0' and set > >>>>>> -g also. > >>>>>> Correct? > >>>>> I am not sure what you mean by 'patch things'. I would simply enable the > >>>>> build system to override the default compilation flags (now DPDK-wide, > >>>>> or specifically librte_ wide) when _DEBUG=y for a library, changing > >>>>> compilation flags from -O3 to -O0 -g and possibly also -fno-inline. I > >>>>> have to check if -O0 already implicitly means -fno-inline (even for > >>>>> __attribute__((always_inline)) ). > >>>>> > >>>>> I did a quick test. I chose KNI because it didn't have a DEBUG flag for > >>>>> the user-space library. For other libraries, the existing _DEBUG setting > >>>>> would be enough: > >>>>> > >>>>> marc@dpdk:~/dpdk$ git diff HEAD > >>>>> diff --git a/config/common_linuxapp b/config/common_linuxapp > >>>>> index 97f1c9e..8a3cef8 100644 > >>>>> --- a/config/common_linuxapp > >>>>> +++ b/config/common_linuxapp > >>>>> @@ -405,6 +405,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y > >>>>> # > >>>>> CONFIG_RTE_LIBRTE_KNI=y > >>>>> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y > >>>>> +CONFIG_RTE_LIBRTE_KNI_DEBUG=y > >>>>> CONFIG_RTE_KNI_KO_DEBUG=n > >>>>> CONFIG_RTE_KNI_VHOST=n > >>>>> CONFIG_RTE_KNI_VHOST_MAX_CACHE_SIZE=1024 > >>>>> diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile > >>>>> index 7107832..895f64e 100644 > >>>>> --- a/lib/librte_kni/Makefile > >>>>> +++ b/lib/librte_kni/Makefile > >>>>> @@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk > >>>>> # library name > >>>>> LIB = librte_kni.a > >>>>> > >>>>> -CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing > >>>>> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) $(CONFIG_RTE_LIBRTE_KNI_CFLAGS) > >>>>> > >>>>> EXPORT_MAP := rte_kni_version.map > >>>>> > >>>>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk > >>>>> index 63a41e2..eee477d 100644 > >>>>> --- a/mk/rte.app.mk > >>>>> +++ b/mk/rte.app.mk > >>>>> @@ -78,6 +78,13 @@ endif > >>>>> ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) > >>>>> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > >>>>> LDLIBS += -lrte_kni > >>>>> + > >>>>> +ifeq ($(CONFIG_RTE_LIBRTE_KNI_DEBUG),y) > >>>>> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O0 -g -fno-strict-aliasing -fno-inline > >>>>> +else > >>>>> +CONFIG_RTE_LIBRTE_KNI_CFLAGS = -O3 -fno-strict-aliasing > >>>>> +endif > >>>>> + > >>>>> endif > >>>>> endif > >>>>> > >>>>> > >>>>> Thoughts? > >>>> My 5c is that if anything, DPDK needs *less* places that muck around with > >>>> compiler flags, not more. If you something like this for all the libraries > >>>> in DPDK the number doesn't just increase a bit, it explodes. > >>> If you check the part below this one in my original email, that you stripped > >>> out (without notice), the suggestion was also to add a global _DEBUG > >>> parameter for the entire DPDK set of libraries, to change all the CFLAGS at > >>> once (not in the attached PATCH). > >>> > >>>> I dont see that much point in this thing, but I'd approach it by defining > >>>> the debug flags someplace central, say DEBUG_FLAGS, and append that to the > >>>> common cflags when *_DEBUG config is enabled. At least with gcc the last > >>>> option wins so if you just append -O0 when debugging then that's what > >>>> wins, the earlier -O3 does not matter. > >>> The original problem is the one you expose; libraries hardcode the CFLAGS, > >>> ignoring user-flags. There is no way to change this unless you change the > >>> Makefiles directly. > >>> > >>> But right now, each library does hardcode its *own* flags (check Makefiles > >>> for the libraries), so there is already not a unified approach here. I see > >>> for instance KNI having -fno-strict-aliasing while other libraries don't. > >>> > >>> Having said that, there are moments, specially with -O3, in which to be able > >>> to reproduce a bug, you need to compile certain parts of code with -O3 and > >>> the rest with -O0 -g (the ones to be debugged). The approach proposed (both > >>> a global *and* a lib specific) allows that. > >>> > >>> Marc > >>> > >> I believe that the global option of overriding the CFLAGS is already sufficiently > >> covered - including being documented in programmers guide - by EXTRA_CFLAGS. The > >> ability to turn off optimization support for a single library is not covered > >> anywhere, and that suggestion seems reasonable to me. For each library, we can > >> just append '-O0 -g' to the CFLAGS in that libraries makefile if the debug option > >> is set. I don't see that as significantly complicating things [though I wouldn't > >> make any changes to the rte.app.mk to allow this, just have it per lib in the > >> lib's makefile] > >> > > Well, but then people would say 'why only -g -O0' for _DEBUG config option? > > And would ask for ability to add/change other compile options to add/change for particular library. > > If we need that, probably we can introduce RTE_LIBRTE_<LIBNAME>_EXTRA_CFLAGS config macros for each library? > > So people can set them in their config files to whatever they like? > > It is not a bad idea either. However, there are already those _DEBUG > config elements (the KNI is a special case). > > Maybe both can be combined (i.e. RTE_LIBRTE_<LIBNAME>_EXTRA_CFLAGS > should always override _DEBUG). It would probably get a bit > over-engineered then, though. I would probably leave _DEBUG config options with what they are doing right now: perform extra checks and generate logs. After all, people might want their program to be more verbose, but they don't want compile options to be changed. Konstantin > > marc > > > > Konstantin ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-03-03 13:03 ` Bruce Richardson 2015-03-03 13:27 ` Marc Sune 2015-03-03 13:31 ` Ananyev, Konstantin @ 2015-03-03 13:32 ` Thomas Monjalon 2 siblings, 0 replies; 22+ messages in thread From: Thomas Monjalon @ 2015-03-03 13:32 UTC (permalink / raw) To: Marc Sune; +Cc: dev 2015-03-03 13:03, Bruce Richardson: > On Tue, Mar 03, 2015 at 01:56:19PM +0100, Marc Sune wrote: > > On 03/03/15 13:40, Panu Matilainen wrote: > > >My 5c is that if anything, DPDK needs *less* places that muck around with > > >compiler flags, not more. If you something like this for all the libraries > > >in DPDK the number doesn't just increase a bit, it explodes. > > > > If you check the part below this one in my original email, that you stripped > > out (without notice), the suggestion was also to add a global _DEBUG > > parameter for the entire DPDK set of libraries, to change all the CFLAGS at > > once (not in the attached PATCH). > > > > >I dont see that much point in this thing, but I'd approach it by defining > > >the debug flags someplace central, say DEBUG_FLAGS, and append that to the > > >common cflags when *_DEBUG config is enabled. At least with gcc the last > > >option wins so if you just append -O0 when debugging then that's what > > >wins, the earlier -O3 does not matter. > > > > The original problem is the one you expose; libraries hardcode the CFLAGS, > > ignoring user-flags. There is no way to change this unless you change the > > Makefiles directly. > > > > But right now, each library does hardcode its *own* flags (check Makefiles > > for the libraries), so there is already not a unified approach here. I see > > for instance KNI having -fno-strict-aliasing while other libraries don't. > > > > Having said that, there are moments, specially with -O3, in which to be able > > to reproduce a bug, you need to compile certain parts of code with -O3 and > > the rest with -O0 -g (the ones to be debugged). The approach proposed (both > > a global *and* a lib specific) allows that. > > > > Marc > > I believe that the global option of overriding the CFLAGS is already sufficiently > covered - including being documented in programmers guide - by EXTRA_CFLAGS. The > ability to turn off optimization support for a single library is not covered > anywhere, and that suggestion seems reasonable to me. For each library, we can > just append '-O0 -g' to the CFLAGS in that libraries makefile if the debug option > is set. I don't see that as significantly complicating things [though I wouldn't > make any changes to the rte.app.mk to allow this, just have it per lib in the > lib's makefile] The difficult thing with a build system, is to know which options and use cases we should support. Today you are suggesting some debug options for gdb. Tomorrow someone would like to have a valgrind support and someone else would like more options for a static analyzer. I think that these usages are restricted to developers use and they already can tune the Makefiles of the libs they are working on. ^ permalink raw reply [flat|nested] 22+ messages in thread
* [dpdk-dev] [PATCH] mk: add support for gdb debug info generation @ 2015-06-19 21:29 Cyril Chemparathy 2015-06-22 7:44 ` Gonzalez Monroy, Sergio 0 siblings, 1 reply; 22+ messages in thread From: Cyril Chemparathy @ 2015-06-19 21:29 UTC (permalink / raw) To: dev From: Cyril Chemparathy <cchemparathy@tilera.com> It is often useful to build with debug enabled, we add a config (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. Note: This patch does not include corresponding changes for ICC. The author pleads abject ignorance in this regard, and welcomes recommendations. :-) Change-Id: I499e591e1b7d71df751fd40d1fdcbe6975eeeb27 Signed-off-by: Cyril Chemparathy <cchemparathy@ezchip.com> --- mk/toolchain/gcc/rte.vars.mk | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk index 0f51c66..22c4c1f 100644 --- a/mk/toolchain/gcc/rte.vars.mk +++ b/mk/toolchain/gcc/rte.vars.mk @@ -71,6 +71,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) endif endif +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) +TOOLCHAIN_CFLAGS += -g -ggdb +TOOLCHAIN_LDFLAGS += -g -ggdb +endif + WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual -- 2.1.2 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-06-19 21:29 Cyril Chemparathy @ 2015-06-22 7:44 ` Gonzalez Monroy, Sergio 2015-06-22 7:56 ` Simon Kågström 2015-06-22 16:41 ` Cyril Chemparathy 0 siblings, 2 replies; 22+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-06-22 7:44 UTC (permalink / raw) To: Cyril Chemparathy, dev On 19/06/2015 22:29, Cyril Chemparathy wrote: > From: Cyril Chemparathy <cchemparathy@tilera.com> > > It is often useful to build with debug enabled, we add a config > (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. > > Note: This patch does not include corresponding changes for ICC. The > author pleads abject ignorance in this regard, and welcomes > recommendations. :-) > > Change-Id: I499e591e1b7d71df751fd40d1fdcbe6975eeeb27 > Signed-off-by: Cyril Chemparathy <cchemparathy@ezchip.com> > --- > mk/toolchain/gcc/rte.vars.mk | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk > index 0f51c66..22c4c1f 100644 > --- a/mk/toolchain/gcc/rte.vars.mk > +++ b/mk/toolchain/gcc/rte.vars.mk > @@ -71,6 +71,11 @@ ifeq (,$(findstring -O0,$(EXTRA_CFLAGS))) > endif > endif > > +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) > +TOOLCHAIN_CFLAGS += -g -ggdb > +TOOLCHAIN_LDFLAGS += -g -ggdb > +endif > + > WERROR_FLAGS := -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes > WERROR_FLAGS += -Wmissing-declarations -Wold-style-definition -Wpointer-arith > WERROR_FLAGS += -Wcast-align -Wnested-externs -Wcast-qual I don't think you need to modify the makefiles and introduce a new compile time option for this. The same result can be easily achieved by setting EXTRA_CFLAGS in the command line. ie: $ make install T=x86_64-native-linuxapp-gcc EXTRA_CFLAGS='-g -ggdb' Sergio ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-06-22 7:44 ` Gonzalez Monroy, Sergio @ 2015-06-22 7:56 ` Simon Kågström 2015-06-23 7:39 ` Gonzalez Monroy, Sergio 2015-06-22 16:41 ` Cyril Chemparathy 1 sibling, 1 reply; 22+ messages in thread From: Simon Kågström @ 2015-06-22 7:56 UTC (permalink / raw) To: dev On 2015-06-22 09:44, Gonzalez Monroy, Sergio wrote: > On 19/06/2015 22:29, Cyril Chemparathy wrote: >> From: Cyril Chemparathy <cchemparathy@tilera.com> >> >> It is often useful to build with debug enabled, we add a config >> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. >> >> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) >> +TOOLCHAIN_CFLAGS += -g -ggdb >> +TOOLCHAIN_LDFLAGS += -g -ggdb >> +endif > I don't think you need to modify the makefiles and introduce a new > compile time option for this. > The same result can be easily achieved by setting EXTRA_CFLAGS in the > command line. ie: > $ make install T=x86_64-native-linuxapp-gcc EXTRA_CFLAGS='-g -ggdb' Why isn't -g standard though? The binaries should/will anyhow be stripped when used for production - but debugging information should be useful when analysing crashes. // Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-06-22 7:56 ` Simon Kågström @ 2015-06-23 7:39 ` Gonzalez Monroy, Sergio 2015-06-23 7:47 ` Thomas Monjalon 0 siblings, 1 reply; 22+ messages in thread From: Gonzalez Monroy, Sergio @ 2015-06-23 7:39 UTC (permalink / raw) To: Simon Kågström, dev On 22/06/2015 08:56, Simon Kågström wrote: > On 2015-06-22 09:44, Gonzalez Monroy, Sergio wrote: >> On 19/06/2015 22:29, Cyril Chemparathy wrote: >>> From: Cyril Chemparathy <cchemparathy@tilera.com> >>> >>> It is often useful to build with debug enabled, we add a config >>> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. >>> >>> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) >>> +TOOLCHAIN_CFLAGS += -g -ggdb >>> +TOOLCHAIN_LDFLAGS += -g -ggdb >>> +endif >> I don't think you need to modify the makefiles and introduce a new >> compile time option for this. >> The same result can be easily achieved by setting EXTRA_CFLAGS in the >> command line. ie: >> $ make install T=x86_64-native-linuxapp-gcc EXTRA_CFLAGS='-g -ggdb' > Why isn't -g standard though? The binaries should/will anyhow be > stripped when used for production - but debugging information should be > useful when analysing crashes. I guess you could argue that, to always build with debug info then strip it down. You would need another flag to strip debug info for production, or leave it for debugging. In my opinion is not worth it, but it you feel strongly about it you can submit patches and let the community decide. Sergio > // Simon > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-06-23 7:39 ` Gonzalez Monroy, Sergio @ 2015-06-23 7:47 ` Thomas Monjalon 2015-06-23 10:08 ` Simon Kågström 0 siblings, 1 reply; 22+ messages in thread From: Thomas Monjalon @ 2015-06-23 7:47 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev 2015-06-23 08:39, Gonzalez Monroy, Sergio: > On 22/06/2015 08:56, Simon Kågström wrote: > > On 2015-06-22 09:44, Gonzalez Monroy, Sergio wrote: > >> On 19/06/2015 22:29, Cyril Chemparathy wrote: > >>> From: Cyril Chemparathy <cchemparathy@tilera.com> > >>> > >>> It is often useful to build with debug enabled, we add a config > >>> (CONFIG_RTE_TOOLCHAIN_DEBUG) to do so. > >>> > >>> +ifeq ($(CONFIG_RTE_TOOLCHAIN_DEBUG),y) > >>> +TOOLCHAIN_CFLAGS += -g -ggdb > >>> +TOOLCHAIN_LDFLAGS += -g -ggdb > >>> +endif > >> I don't think you need to modify the makefiles and introduce a new > >> compile time option for this. > >> The same result can be easily achieved by setting EXTRA_CFLAGS in the > >> command line. ie: > >> $ make install T=x86_64-native-linuxapp-gcc EXTRA_CFLAGS='-g -ggdb' > > Why isn't -g standard though? The binaries should/will anyhow be > > stripped when used for production - but debugging information should be > > useful when analysing crashes. > > I guess you could argue that, to always build with debug info then strip > it down. > You would need another flag to strip debug info for production, or leave > it for debugging. > > In my opinion is not worth it, but it you feel strongly about it you can > submit patches and > let the community decide. I think stripping is a packaging responsibility. It would be a good idea to always provide debugging symbols. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-06-23 7:47 ` Thomas Monjalon @ 2015-06-23 10:08 ` Simon Kågström 0 siblings, 0 replies; 22+ messages in thread From: Simon Kågström @ 2015-06-23 10:08 UTC (permalink / raw) To: Thomas Monjalon, Gonzalez Monroy, Sergio; +Cc: dev On 2015-06-23 09:47, Thomas Monjalon wrote: > 2015-06-23 08:39, Gonzalez Monroy, Sergio: >> I guess you could argue that, to always build with debug info then strip >> it down. >> You would need another flag to strip debug info for production, or leave >> it for debugging. >> >> In my opinion is not worth it, but it you feel strongly about it you can >> submit patches and >> let the community decide. > > I think stripping is a packaging responsibility. > It would be a good idea to always provide debugging symbols. Yes, I think this would be the best way too, and should be pretty much standard procedure. DPDK is anyhow just a library - stripping should be up to the application / packaging to do. // Simon ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation 2015-06-22 7:44 ` Gonzalez Monroy, Sergio 2015-06-22 7:56 ` Simon Kågström @ 2015-06-22 16:41 ` Cyril Chemparathy 1 sibling, 0 replies; 22+ messages in thread From: Cyril Chemparathy @ 2015-06-22 16:41 UTC (permalink / raw) To: Gonzalez Monroy, Sergio; +Cc: dev On Mon, 22 Jun 2015 08:44:41 +0100 "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com> wrote: > I don't think you need to modify the makefiles and introduce a new > compile time option for this. > The same result can be easily achieved by setting EXTRA_CFLAGS in the > command line. ie: > $ make install T=x86_64-native-linuxapp-gcc EXTRA_CFLAGS='-g > -ggdb' Fair enough. Please ignore this patch then. Thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2015-06-23 10:08 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-03 17:31 [dpdk-dev] [PATCH] mk: add support for gdb debug info generation Cyril Chemparathy 2014-04-04 9:57 ` Ananyev, Konstantin 2015-02-22 11:51 ` Marc Sune 2015-03-02 17:32 ` Marc Sune 2015-03-03 9:33 ` Bruce Richardson 2015-03-03 12:19 ` Marc Sune 2015-03-03 12:40 ` Panu Matilainen 2015-03-03 12:56 ` Marc Sune 2015-03-03 13:03 ` Bruce Richardson 2015-03-03 13:27 ` Marc Sune 2015-03-04 9:44 ` Olivier MATZ 2015-03-03 13:31 ` Ananyev, Konstantin 2015-03-03 14:39 ` Marc Sune 2015-03-03 16:24 ` Ananyev, Konstantin 2015-03-03 13:32 ` Thomas Monjalon 2015-06-19 21:29 Cyril Chemparathy 2015-06-22 7:44 ` Gonzalez Monroy, Sergio 2015-06-22 7:56 ` Simon Kågström 2015-06-23 7:39 ` Gonzalez Monroy, Sergio 2015-06-23 7:47 ` Thomas Monjalon 2015-06-23 10:08 ` Simon Kågström 2015-06-22 16:41 ` Cyril Chemparathy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).