--enable-debug does not work with gcc
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:
***************
# supply -g if --enable-debug
! if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then
CFLAGS="$CFLAGS -g"
fi
--- 300,315 ---- # supply -g if --enable-debug
! if test "$enable_debug" = yes && (test "$ac_cv_prog_cc_g" = yes ||
! test "$ac_cv_prog_gcc_g" = yes); then
CFLAGS="$CFLAGS -g"
fi
Should I submit a patch for this?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
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
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,
On 2/2/07, Gavin Sherry <swm@alcove.com.au> wrote:
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 outa
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.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 every compile.
---------------------------------------------------------------------------
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. +