Re: [dpdk-dev] [PATCH] mk: add support for gdb debug info generation

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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.