All of lore.kernel.org
 help / color / mirror / Atom feed
From: Panu Matilainen <pmatilai-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: dev-VfR2kkLFssw@public.gmane.org
Subject: Re: [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-kpkqNMk1I7M@public.gmane.org>

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 -

  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 [PATCH] mk: add support for gdb debug info generation Cyril Chemparathy
     [not found] ` <1396546285-29972-1-git-send-email-cchemparathy-kv+TWInifGbQT0dZR+AlfA@public.gmane.org>
2014-04-04  9:57   ` Ananyev, Konstantin
     [not found]     ` <2601191342CEEE43887BDE71AB9772580EF948F7-kPTMFJFq+rEu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-02-22 11:51       ` Marc Sune
     [not found]         ` <54E9C2C0.3090108-kpkqNMk1I7M@public.gmane.org>
2015-03-02 17:32           ` Marc Sune
     [not found]             ` <54F49E9D.6070201-kpkqNMk1I7M@public.gmane.org>
2015-03-03  9:33               ` Bruce Richardson
2015-03-03 12:19                 ` Marc Sune
     [not found]                   ` <54F5A6CF.2090203-kpkqNMk1I7M@public.gmane.org>
2015-03-03 12:40                     ` Panu Matilainen [this message]
     [not found]                       ` <54F5ABCA.4010707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-03 12:56                         ` Marc Sune
     [not found]                           ` <54F5AF73.1060109-kpkqNMk1I7M@public.gmane.org>
2015-03-03 13:03                             ` Bruce Richardson
2015-03-03 13:27                               ` Marc Sune
     [not found]                                 ` <54F5B6CD.7090209-kpkqNMk1I7M@public.gmane.org>
2015-03-04  9:44                                   ` Olivier MATZ
2015-03-03 13:31                               ` Ananyev, Konstantin
     [not found]                                 ` <2601191342CEEE43887BDE71AB977258213F38C9-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-03-03 14:39                                   ` Marc Sune
     [not found]                                     ` <54F5C79F.1090705-kpkqNMk1I7M@public.gmane.org>
2015-03-03 16:24                                       ` Ananyev, Konstantin
2015-03-03 13:32                               ` Thomas Monjalon
  -- strict thread matches above, loose matches on Subject: below --
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-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.