From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
To: "Simon Kågström" <simon.kagstrom@netinsight.net>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation
Date: Tue, 23 Jun 2015 08:39:38 +0100 [thread overview]
Message-ID: <55890D3A.109@intel.com> (raw)
In-Reply-To: <5587BFA7.2000206@netinsight.net>
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
>
next prev parent reply other threads:[~2015-06-23 7:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 21:29 Cyril Chemparathy
2015-06-19 21:29 ` [dpdk-dev] [PATCH] examples/l2fwd: Add forward count limit Cyril Chemparathy
2015-07-10 14:20 ` Thomas Monjalon
2015-06-22 7:44 ` [dpdk-dev] [PATCH] mk: add support for gdb debug info generation Gonzalez Monroy, Sergio
2015-06-22 7:56 ` Simon Kågström
2015-06-23 7:39 ` Gonzalez Monroy, Sergio [this message]
2015-06-23 7:47 ` Thomas Monjalon
2015-06-23 10:08 ` Simon Kågström
2015-06-22 16:41 ` Cyril Chemparathy
-- strict thread matches above, loose matches on Subject: below --
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
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
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=55890D3A.109@intel.com \
--to=sergio.gonzalez.monroy@intel.com \
--cc=dev@dpdk.org \
--cc=simon.kagstrom@netinsight.net \
/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).