DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Marc Sune <marc.sune@bisdn.de>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation
Date: Tue, 3 Mar 2015 09:33:55 +0000	[thread overview]
Message-ID: <20150303093355.GA7300@bricha3-MOBL3> (raw)
In-Reply-To: <54F49E9D.6070201@bisdn.de>

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
> >>
> >
> 

  reply	other threads:[~2015-03-03  9:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03 17:31 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150303093355.GA7300@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=marc.sune@bisdn.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).