Обсуждение: --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
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
On 2/2/07, Gavin Sherry <swm@alcove.com.au> wrote:
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
--
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,
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
On 2/2/07, Gavin Sherry <swm@alcove.com.au> wrote:
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? 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.
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. +