pgman wrote:
> Jan Wieck wrote:
> > >> >> > What Peter was advocating in that thread was that we enable -g by
> > >> >> > default *when building with gcc*.  I have no problem with that, since
> > >> >> > there is (allegedly) no performance penalty for -g with gcc.  However,
> > >> >> > the actual present behavior of our configure script is to default to -g
> > >> >> > for every compiler, and I think that that is a big mistake.  On most
> > >> >> > non-gcc compilers, -g disables optimizations, which is way too high a
> > >> >> > price to pay for production use.
> > >> >> 
> > >> >> You do realize that as of now, -g is the default for gcc?  Was that the
> > >> >> intent?
> > >> > 
> > >> > I was going to ask that myself.  It seems strange to include -g by default ---
> > >> > we have --enable-debug, and that should control -g on all platforms.
> > >> 
> > >> Could it be that there ought to be a difference between the defaults of 
> > >> a devel CVS tree, a BETA tarball and a final "production" release?
> > > 
> > > I am afraid that adds too much confusion to the debug situation.  We
> > > have a flag to do -g;  let people use it if they want it.
> > > 
> > 
> > Well, -g eats up some disk space, but for a gcc it doesn't need CPU 
> > cycles or anything else. I doubt many people who pay the horrible 
> > storage capacity overhead for PostgreSQL are that concerned about some 
> > extra symbols stored with their binaries, but let's not argue about that 
> > one.
> 
> Well, people are stripping the executable, so some of them must care. 
> In fact, if we enable -g by default for gcc, how do compile with default
> symbols?  We would need another configure option.  Strip is not the same
> as default symbols.

Let me also add that on my old dual P3 550 256MB RAM -g significantly
slowed down the build because linking took a long time, probably because
it had to read in all those debug symbols for the link --- I remember
the backend link taking quite a lot of time.

In fact, even though I was debugging the backend regularly, I removed -g
and added it only when I wanted to debug.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 27 Oct 2003 11:05:58 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote:

> pgman wrote:
>> Jan Wieck wrote:
>> > >> >> > What Peter was advocating in that thread was that we enable -g by
>> > >> >> > default *when building with gcc*.  I have no problem with that, since
>> > >> >> > there is (allegedly) no performance penalty for -g with gcc.  However,
>> > >> >> > the actual present behavior of our configure script is to default to -g
>> > >> >> > for every compiler, and I think that that is a big mistake.  On most
>> > >> >> > non-gcc compilers, -g disables optimizations, which is way too high a
>> > >> >> > price to pay for production use.
>> > >> >> 
>> > >> >> You do realize that as of now, -g is the default for gcc?  Was that the
>> > >> >> intent?
>> > >> > 
>> > >> > I was going to ask that myself.  It seems strange to include -g by default ---
>> > >> > we have --enable-debug, and that should control -g on all platforms.
>> > >> 
>> > >> Could it be that there ought to be a difference between the defaults of 
>> > >> a devel CVS tree, a BETA tarball and a final "production" release?
>> > > 
>> > > I am afraid that adds too much confusion to the debug situation.  We
>> > > have a flag to do -g;  let people use it if they want it.
>> > > 
>> > 
>> > Well, -g eats up some disk space, but for a gcc it doesn't need CPU 
>> > cycles or anything else. I doubt many people who pay the horrible 
>> > storage capacity overhead for PostgreSQL are that concerned about some 
>> > extra symbols stored with their binaries, but let's not argue about that 
>> > one.
>> 
>> Well, people are stripping the executable, so some of them must care. 
>> In fact, if we enable -g by default for gcc, how do compile with default
>> symbols?  We would need another configure option.  Strip is not the same
>> as default symbols.
> 
> Let me also add that on my old dual P3 550 256MB RAM -g significantly
> slowed down the build because linking took a long time, probably because
> it had to read in all those debug symbols for the link --- I remember
> the backend link taking quite a lot of time.
> 
> In fact, even though I was debugging the backend regularly, I removed -g
> and added it only when I wanted to debug.
> 

It did somethimes in the past proove to be good luck to have symbols in 
a core file accidentially. If you want to find them in an arbitrary out 
of the box installation, they have to be in the default configuration. 
That they cannot be there if a non-gcc does not optimize the code then, 
sure. But I don't really see the confusion you're talking about. Nor do 
I see the importance of link-time when setting up a production system 
from sources. Do not mix up developer usage with DBA usage. You can ask 
a developer to use "--disable-debug", and when he complains about slow 
compiles it's still time to tell him. But if you expect a DBA to 
configure "--enable-debug" you will get core files that are plain 
useless and it's too late.

What I would like to maintain is the best possible support capability 
(finding symbols wherever possible to do the aftermath of a crashed 
backend), while providing the best possible performance - with 
performance having priority. That this leads to different options used 
on different platforms and compilers, so be it.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Mon, 27 Oct 2003 16:41:29 -0500
Jan Wieck <JanWieck@Yahoo.com>
Re: Still a few flaws in configure's default CFLAGS selection
Jan Wieck wrote:
> > In fact, even though I was debugging the backend regularly, I removed -g
> > and added it only when I wanted to debug.
> > 
> 
> It did somethimes in the past proove to be good luck to have symbols in 
> a core file accidentially. If you want to find them in an arbitrary out 
> of the box installation, they have to be in the default configuration. 
> That they cannot be there if a non-gcc does not optimize the code then, 
> sure. But I don't really see the confusion you're talking about. Nor do 
> I see the importance of link-time when setting up a production system 
> from sources. Do not mix up developer usage with DBA usage. You can ask 
> a developer to use "--disable-debug", and when he complains about slow 
> compiles it's still time to tell him. But if you expect a DBA to 
> configure "--enable-debug" you will get core files that are plain 
> useless and it's too late.
> 
> What I would like to maintain is the best possible support capability 
> (finding symbols wherever possible to do the aftermath of a crashed 
> backend), while providing the best possible performance - with 
> performance having priority. That this leads to different options used 
> on different platforms and compilers, so be it.

This leaves us with "--enable-debug" for non-gcc compilers, and adding
"--disable-debug" for gcc compilers.

Right now configure --help has:

  --enable-debug          build with debugging symbols (-g)

If people want to add --disable-debug, and document which is gcc and
non-gcc, that is fine with me.

Also, usually, you don't want to run the debugger on optimized code
unless you are debugging a compiler issue, so maybe we should call it
--debugging-symbols and --no-debugging-symbols to make it clear what the
option does.

Also, we should encourage packages to use --no-debugging-symbols rather
than 'strip'.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 27 Oct 2003 16:59:50 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Still a few flaws in configure's default CFLAGS selection
Bruce Momjian wrote:
> Jan Wieck wrote:
>> > In fact, even though I was debugging the backend regularly, I removed -g
>> > and added it only when I wanted to debug.
>> > 
>> 
>> It did somethimes in the past proove to be good luck to have symbols in 
>> a core file accidentially. If you want to find them in an arbitrary out 
>> of the box installation, they have to be in the default configuration. 
>> That they cannot be there if a non-gcc does not optimize the code then, 
>> sure. But I don't really see the confusion you're talking about. Nor do 
>> I see the importance of link-time when setting up a production system 
>> from sources. Do not mix up developer usage with DBA usage. You can ask 
>> a developer to use "--disable-debug", and when he complains about slow 
>> compiles it's still time to tell him. But if you expect a DBA to 
>> configure "--enable-debug" you will get core files that are plain 
>> useless and it's too late.
>> 
>> What I would like to maintain is the best possible support capability 
>> (finding symbols wherever possible to do the aftermath of a crashed 
>> backend), while providing the best possible performance - with 
>> performance having priority. That this leads to different options used 
>> on different platforms and compilers, so be it.
> 
> This leaves us with "--enable-debug" for non-gcc compilers, and adding
> "--disable-debug" for gcc compilers.
> 
> Right now configure --help has:
> 
>   --enable-debug          build with debugging symbols (-g)
> 
> If people want to add --disable-debug, and document which is gcc and
> non-gcc, that is fine with me.
> 
> Also, usually, you don't want to run the debugger on optimized code
> unless you are debugging a compiler issue, so maybe we should call it
> --debugging-symbols and --no-debugging-symbols to make it clear what the
> option does.

I never "want" to run any debugger, I am sometimes "forced" to do so and 
then the more symbols I have the better. Debugging optimized code can 
lead to some confusion as the optimizer is allowed to reorder code 
execution or keep variables in registers instead of on the stack and 
thus, the flow of instructions is not in sync with the sourcecode, what 
makes it kinda hard sometimes to set breakpoints or to see what 
statements actually have NOT been executed already when looking at a  file.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Mon, 27 Oct 2003 20:44:21 -0500
Jan Wieck <JanWieck@Yahoo.com>
Re: Still a few flaws in configure's default CFLAGS selection