From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id ABECA5A95 for ; Tue, 3 Mar 2015 14:33:10 +0100 (CET) Received: by widex7 with SMTP id ex7so22780560wid.4 for ; Tue, 03 Mar 2015 05:33:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=YhPMWeF5FWiHEt+Av7Wj/ysqJ85QPsijwqw2xajyW2w=; b=Wj0Mo5/nx4C0AKEISX59RFOmAMCe5/7AqU9eMwQq2tc+UWb2gTFrzg5ILF06drFDag TF19rQ1Bkel8sc4v1Kg8WskSqlXIlfp7pPTlsLEv6unXhw9xxhZI6exIY6A9Ew6QOzgy //j/0EfRkUlA5S8M9r7FNMlJ2i4pzhP1OUf9y9kbfO0ENAwYnZPmm/wshYIYMSXD5Zy7 N5VXD4mPp61Xpz6WwNDUpTRdENgheBFUwxg1V6QylNXoSFhqua8kKSXWsWE38huNWWNQ loxgP+6bSFbuflBM8sXVjH9fovF1cPAZ0FIIMyD/WD/DsVnvhsglFzvN16K4DXTAdTD+ XLQA== X-Gm-Message-State: ALoCoQm+7BaoETKssFN+RbYSCI599gGJC0jbED8B6ul2WOdoZ4C8H1nAQLhiIGgEVMmYyy9rjaM6 X-Received: by 10.194.86.135 with SMTP id p7mr70387696wjz.89.1425389590514; Tue, 03 Mar 2015 05:33:10 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id b4sm20625509wic.2.2015.03.03.05.33.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 05:33:09 -0800 (PST) From: Thomas Monjalon To: Marc Sune Date: Tue, 03 Mar 2015 14:32:36 +0100 Message-ID: <1653665.mL9en1i6hD@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <20150303130301.GA11084@bricha3-MOBL3> References: <1396546285-29972-1-git-send-email-cchemparathy@tilera.com> <54F5AF73.1060109@bisdn.de> <20150303130301.GA11084@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 13:33:11 -0000 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.