Thread: --enable-debug does not work with gcc

Hi, <br /><br />configure with --enable-debug does not seem to add "-g" to CFLAGS while compiling with gcc. Guess we
willneed to change <a href="http://configure.in">configure.in</a> as below:<br /><br />*************** <br /><br />  #
supply-g if --enable-debug<br />! if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then<br />   
CFLAGS="$CFLAGS-g"<br />  fi<br />--- 300,315 ----<br /><br />  # supply -g if --enable-debug <br />! if test
"$enable_debug"= yes && (test "$ac_cv_prog_cc_g" = yes ||<br />!       test "$ac_cv_prog_gcc_g" = yes); then<br
/>   CFLAGS="$CFLAGS -g"<br />  fi<br /><br clear="all" /><br />Should I submit a patch for this?<br /><br
/>Regards,<br/>Nikhils<br />-- <br />EnterpriseDB               <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a>

On Fri, 2 Feb 2007, NikhilS wrote:

> Hi,
>
> configure with --enable-debug does not seem to add "-g" to CFLAGS while
> compiling with gcc. Guess we will need to change configure.in as below:

Erm... works for me and everyone else... AFAIK.

Thanks,

Gavin

Hi,

Indeed it does, apologies for not doing the entire groundwork. But what it also does is that it adds -O2 by default for gcc even when --enable-debug is specified. gdb is not able to navigate the stack traces properly with this optimization in place. Especially tracing of static functions becomes difficult. Has this issue been faced by anybody else? If so can try out a patch to avoid using O2 with enable-debug.

Regards,
Nikhils




--
EnterpriseDB               http://www.enterprisedb.com

On Fri, 2 Feb 2007, NikhilS wrote:

> Hi,
>
> Indeed it does, apologies for not doing the entire groundwork. But what it
> also does is that it adds -O2 by default for gcc even when --enable-debug is
> specified. gdb is not able to navigate the stack traces properly with this
> optimization in place. Especially tracing of static functions becomes
> difficult. Has this issue been faced by anybody else? If so can try out a
> patch to avoid using O2 with enable-debug.

Yes, this is known. The thing with gcc is, it only emits some warnings at
-O2. I'm not that this is why we do not set optimisation to 0 but have
long assumed it to be the case. I imagine that it's fairly standard
practice for people doing debugging to CFLAGS=-O0 as an argument to
configure.

Hi,

True, this is how I myself circumvent this problem too. But IMHO, explicitly passing CFLAGS when we are invoking --enable-debug (which does add -g, but leaves some optimization flag around which deters debugging) does not seem correct?

Regards,
Nikhils


--
EnterpriseDB               http://www.enterprisedb.com

NikhilS <nikkhils@gmail.com> writes:
> True, this is how I myself circumvent this problem too. But IMHO,
> explicitly passing CFLAGS when we are invoking --enable-debug (which does
> add -g, but leaves some optimization flag around which deters debugging)
> does not seem correct?

If we did what you suggest, then --enable-debug would cause performance
degradation, which would cause people to not use it, which would result
in most binaries being completely undebuggable rather than only partially.
Doesn't sound like a good tradeoff to me.

Personally, in my development tree I use a Makefile.custom containing

# back off optimization unless profiling
ifeq ($(PROFILE),)  CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS))
endif

-O1 still generates "uninitialized variable" warnings but the code is a
lot saner to step through ... not perfect, but saner.  It's been a
workable compromise for a long time.  I don't recommend developing with
-O0, exactly because it disables some mighty valuable warnings.
        regards, tom lane

Tom Lane wrote:
> NikhilS <nikkhils@gmail.com> writes:
> > True, this is how I myself circumvent this problem too. But IMHO,
> > explicitly passing CFLAGS when we are invoking --enable-debug (which does
> > add -g, but leaves some optimization flag around which deters debugging)
> > does not seem correct?
> 
> If we did what you suggest, then --enable-debug would cause performance
> degradation, which would cause people to not use it, which would result
> in most binaries being completely undebuggable rather than only partially.
> Doesn't sound like a good tradeoff to me.
> 
> Personally, in my development tree I use a Makefile.custom containing
> 
> # back off optimization unless profiling
> ifeq ($(PROFILE),)
>    CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS))
> endif
> 
> -O1 still generates "uninitialized variable" warnings but the code is a
> lot saner to step through ... not perfect, but saner.  It's been a
> workable compromise for a long time.  I don't recommend developing with
> -O0, exactly because it disables some mighty valuable warnings.

Agreed.  I use -O1 by default myself, unless I am doing performance testing.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

>> If we did what you suggest, then --enable-debug would cause performance
>> degradation, which would cause people to not use it, which would result
>> in most binaries being completely undebuggable rather than only partially.
>> Doesn't sound like a good tradeoff to me.
>>
>> Personally, in my development tree I use a Makefile.custom containing
>>
>> # back off optimization unless profiling
>> ifeq ($(PROFILE),)
>>    CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS))
>> endif
>>
>> -O1 still generates "uninitialized variable" warnings but the code is a
>> lot saner to step through ... not perfect, but saner.  It's been a
>> workable compromise for a long time.  I don't recommend developing with
>> -O0, exactly because it disables some mighty valuable warnings.
> 
> Agreed.  I use -O1 by default myself, unless I am doing performance testing.
> 
Something for the developers FAQ perhaps? I confess I did not know of
Makefile.custom :-D

//Magnus

Hi all,

Magnus Hagander wrote:
>>> Personally, in my development tree I use a Makefile.custom containing
>>>
>>> # back off optimization unless profiling
>>> ifeq ($(PROFILE),)
>>>    CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS))
>>> endif
>>>
>>> -O1 still generates "uninitialized variable" warnings but the code is a
>>> lot saner to step through ... not perfect, but saner.  It's been a
>>> workable compromise for a long time.  I don't recommend developing with
>>> -O0, exactly because it disables some mighty valuable warnings.
>> Agreed.  I use -O1 by default myself, unless I am doing performance testing.
>>
> Something for the developers FAQ perhaps? I confess I did not know of
> Makefile.custom :-D

I did not know, either, but would have been glad, had I found such info
a few weeks ago when I started digging into the pg source ;)

And while we are at it, how about some CFLAGS="-DOPTIMIZER_DEBUG"
sweetness for the debugging section in the Dev FAQ?

Are there any other macros that enable some more debug output? (Or is
there a place where all this has already been documented?)

Cheers,
Matthias

Matthias Luedtke wrote:
> And while we are at it, how about some CFLAGS="-DOPTIMIZER_DEBUG"
> sweetness for the debugging section in the Dev FAQ?

Most of the debugging macros are not documented because their purpose 
only arises out of the source code.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Added to developer's FAQ:
   <P><I>src/Makefile.custom</I> can be used to set environment variables,   like <I>CUSTOM_COPT</I>, that are used for
everycompile.
 



---------------------------------------------------------------------------

Magnus Hagander wrote:
> >> If we did what you suggest, then --enable-debug would cause performance
> >> degradation, which would cause people to not use it, which would result
> >> in most binaries being completely undebuggable rather than only partially.
> >> Doesn't sound like a good tradeoff to me.
> >>
> >> Personally, in my development tree I use a Makefile.custom containing
> >>
> >> # back off optimization unless profiling
> >> ifeq ($(PROFILE),)
> >>    CFLAGS:= $(patsubst -O2,-O1,$(CFLAGS))
> >> endif
> >>
> >> -O1 still generates "uninitialized variable" warnings but the code is a
> >> lot saner to step through ... not perfect, but saner.  It's been a
> >> workable compromise for a long time.  I don't recommend developing with
> >> -O0, exactly because it disables some mighty valuable warnings.
> > 
> > Agreed.  I use -O1 by default myself, unless I am doing performance testing.
> > 
> Something for the developers FAQ perhaps? I confess I did not know of
> Makefile.custom :-D
> 
> //Magnus
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +