From: Panu Matilainen <pmatilai@redhat.com>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation
Date: Tue, 03 Mar 2015 14:40:42 +0200 [thread overview]
Message-ID: <54F5ABCA.4010707@redhat.com> (raw)
In-Reply-To: <54F5A6CF.2090203@bisdn.de>
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 -
next prev parent reply other threads:[~2015-03-03 12:40 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
2015-03-03 12:19 ` Marc Sune
2015-03-03 12:40 ` Panu Matilainen [this message]
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=54F5ABCA.4010707@redhat.com \
--to=pmatilai@redhat.com \
--cc=dev@dpdk.org \
/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).