Thread: Still a few flaws in configure's default CFLAGS selection
While fooling with adding -fno-strict-aliasing to configure, I realized
that there are still some oddities about its selection of CFLAGS. The
problems stem from the fact that autoconf will always select a default
value of CFLAGS that includes "-g", if the compiler accepts "-g" at all.
This has a couple of consequences:
1. --enable-debug is nearly useless, since unless you've manually
specified CFLAGS, what you're going to get will include -g anyway.
2. The code Bruce put in to default to "-O" on non-gcc compilers
will never actually fire.
It would be fairly easy to override autoconf's behavior, but I wonder
whether that will surprise people who are used to the "standard"
behavior of autoconf scripts. Personally I've always felt that
defaulting to -g was a bizarre and unwise choice on the part of the
autoconf developers, but maybe someone out there wants to defend it?
Comments anyone?
regards, tom lane
Tom Lane wrote: > While fooling with adding -fno-strict-aliasing to configure, I realized > that there are still some oddities about its selection of CFLAGS. The > problems stem from the fact that autoconf will always select a default > value of CFLAGS that includes "-g", if the compiler accepts "-g" at all. > This has a couple of consequences: > > 1. --enable-debug is nearly useless, since unless you've manually > specified CFLAGS, what you're going to get will include -g anyway. > > 2. The code Bruce put in to default to "-O" on non-gcc compilers > will never actually fire. I see that now. I saw in configure:if test "$ac_test_CFLAGS" = set; then CFLAGS=$ac_save_CFLAGSelif test $ac_cv_prog_cc_g= yes; then if test "$GCC" = yes; then CFLAGS="-g -O2" else CFLAGS="-g" fielse if test "$GCC" =yes; then CFLAGS="-O2" else CFLAGS= fifi and assumed the CFLAGS= line was the default, and thought the $ac_cv_prog_cc_g = yes test was for debug enabled. Now I see it just checks if -g works and uses it unconditionally. That is bizarre. I was never even fond of configure defaulting to -O2. It is a fine default, but the CFLAGS default should be our decision, not configure. > It would be fairly easy to override autoconf's behavior, but I wonder > whether that will surprise people who are used to the "standard" > behavior of autoconf scripts. Personally I've always felt that > defaulting to -g was a bizarre and unwise choice on the part of the > autoconf developers, but maybe someone out there wants to defend it? Agreed. What does autoconf know about our project? Nothing. We should not default to their compile flages. -- 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, Pennsylvania19073
Tom Lane <tgl@sss.pgh.pa.us> writes: > It would be fairly easy to override autoconf's behavior, but I wonder > whether that will surprise people who are used to the "standard" > behavior of autoconf scripts. Personally I've always felt that > defaulting to -g was a bizarre and unwise choice on the part of the > autoconf developers, but maybe someone out there wants to defend it? uh, since you asked. I think the logic is that, at least with gcc, -g is never harmful since you can compile with -O and -g and then strip later if necessary. Does it still default to -g with compilers that cannot do -O and -g together? Also, RMS happens to think all binaries should be installed with symbols. I think he's seen far too many emacs bug reports where the user was unable to provide any useful bug report because the binary was stripped. The space needed is usually (but not always) fairly minimal anyways. Personally I tend to agree with this. It always annoys me that the first thing I have to do when I try to track down a bug is download the source and recompile the program. But I don't think that's the logic behind the autoconf defaults, only a bit of useful context. -- greg
Greg Stark <gsstark@mit.edu> writes:
> uh, since you asked. I think the logic is that, at least with gcc, -g
> is never harmful since you can compile with -O and -g and then strip
> later if necessary.
Yeah, but ...
> Does it still default to -g with compilers that
> cannot do -O and -g together?
*Yes*. This is exactly the problem, really. One could reasonably
accuse the autoconf developers of FSF imperialism, because they have
seen to it that autoconf-based configure scripts will choose non-optimal
CFLAGS for non-gcc compilers. These same geeks would be screaming for
Microsoft's blood if Microsoft tried comparable tactics, so I don't have
a whole lot of sympathy.
(Side note: I've been overriding this particular autoconf-ism in
libjpeg's configure script since about 1995, so it's not like my
antipathy to it is a new subject.)
> Also, RMS happens to think all binaries should be installed with symbols. I
> think he's seen far too many emacs bug reports where the user was unable to
> provide any useful bug report because the binary was stripped.
I hear where he's coming from, believe me. But RPM builds generally strip
the binaries anyway, so autoconf isn't really accomplishing anything
with this that I can see. The mass market won't be providing stack
traces with their bug reports, whether the binary has symbols or not.
regards, tom lane
Tom Lane writes: > *Yes*. This is exactly the problem, really. One could reasonably > accuse the autoconf developers of FSF imperialism, because they have > seen to it that autoconf-based configure scripts will choose non-optimal > CFLAGS for non-gcc compilers. These same geeks would be screaming for > Microsoft's blood if Microsoft tried comparable tactics, so I don't have > a whole lot of sympathy. The philosophy of the autotools is to give power to the experienced user (you can set your own CFLAGS) and to give portable defaults to everyone else (-O is technically not portable). Another contributing factor is that the default stems from a different era, one might say, and has been the same for a long time, and changing it now would probably upset as many people as it would please. In other news, if you don't like what autoconf does and you are confident about what your compiler can handle, you are free to set up a config.status file or set CFLAGS in your environment. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> [ griping about autoconf's default choices for CFLAGS ]
> The philosophy of the autotools is to give power to the experienced user
> (you can set your own CFLAGS) and to give portable defaults to everyone
> else (-O is technically not portable).
It'd be nicer if they had tried to give *useful* defaults to everyone else.
The existing behavior is reasonable for people testing beta-quality
software, but it's not a helpful choice for production code. It's great
that someone who knows what they're doing can override it, but right now
I'm concerned with the default build behavior for people who don't know.
> Another contributing factor is
> that the default stems from a different era, one might say, and has been
> the same for a long time, and changing it now would probably upset as many
> people as it would please.
FWIW, I've been overriding the default CFLAGS to be -O for non-gcc in
libjpeg's configure script since [...digs...] release 6b of March 1998.
I've yet to hear any complaint about it, and that code is used on a much
wider variety of systems than Postgres runs on. So my opinion is that
-O is perfectly portable and unlikely to upset anyone for production
code --- especially when configure advertises a switch to select -g
instead.
regards, tom lane
Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > > uh, since you asked. I think the logic is that, at least with gcc, -g > > is never harmful since you can compile with -O and -g and then strip > > later if necessary. > > Yeah, but ... > > > Does it still default to -g with compilers that > > cannot do -O and -g together? > > *Yes*. This is exactly the problem, really. One could reasonably > accuse the autoconf developers of FSF imperialism, because they have > seen to it that autoconf-based configure scripts will choose non-optimal > CFLAGS for non-gcc compilers. These same geeks would be screaming for > Microsoft's blood if Microsoft tried comparable tactics, so I don't have > a whole lot of sympathy. > > (Side note: I've been overriding this particular autoconf-ism in > libjpeg's configure script since about 1995, so it's not like my > antipathy to it is a new subject.) > > > Also, RMS happens to think all binaries should be installed with symbols. I > > think he's seen far too many emacs bug reports where the user was unable to > > provide any useful bug report because the binary was stripped. > > I hear where he's coming from, believe me. But RPM builds generally strip > the binaries anyway, so autoconf isn't really accomplishing anything > with this that I can see. The mass market won't be providing stack > traces with their bug reports, whether the binary has symbols or not. Also, -g is not the opposite of strip. A default compile adds function name symbols. -g adds debug symbols, strip removes all symbols, so a compile that uses -g and strip has fewer symbols than one that does a compile without -g and without strip. Also, I thought Peter advocated adding -g a few releases back. I didn't agree, but I lost the vote, so I thought it was done. Were we supresssing -g in older releases? Peter? -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, I thought Peter advocated adding -g a few releases back. I didn't
> agree, but I lost the vote, so I thought it was done. Were we
> supresssing -g in older releases? Peter?
I don't recall any such vote. Had we done that, we'd have removed
--enable-debug, I'd think.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Also, I thought Peter advocated adding -g a few releases back. I didn't > > agree, but I lost the vote, so I thought it was done. Were we > > supresssing -g in older releases? Peter? > > I don't recall any such vote. Had we done that, we'd have removed > --enable-debug, I'd think. The vote was whether -g should be used for a default compile. Of course --enable-debug would continue using -g. Maybe we kept --enable-debug for backward compatibility or to force -g if you modified CFLAGS? -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The vote was whether -g should be used for a default compile. Of course
> --enable-debug would continue using -g. Maybe we kept --enable-debug
> for backward compatibility or to force -g if you modified CFLAGS?
I can't see why we would have kept --enable-debug if we intended to make
-g be default anyway. Backwards compatibility is not an issue, because
configure simply ignores --enable switches it doesn't recognize (another
questionable autoconf design decision, but I digress). And if you are
setting CFLAGS for yourself, you are surely capable of adding -g to it
if you want; why would you type seven times as much to accomplish the
same thing?
regards, tom lane
Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Also, I thought Peter advocated adding -g a few releases back. I didn't > > > agree, but I lost the vote, so I thought it was done. Were we > > > supresssing -g in older releases? Peter? > > > > I don't recall any such vote. Had we done that, we'd have removed > > --enable-debug, I'd think. > > The vote was whether -g should be used for a default compile. Of course > --enable-debug would continue using -g. Maybe we kept --enable-debug > for backward compatibility or to force -g if you modified CFLAGS? Here is the thread discussing the -g flag: http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php -- 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, Pennsylvania19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > The vote was whether -g should be used for a default compile. Of course > > --enable-debug would continue using -g. Maybe we kept --enable-debug > > for backward compatibility or to force -g if you modified CFLAGS? > > I can't see why we would have kept --enable-debug if we intended to make > -g be default anyway. Backwards compatibility is not an issue, because > configure simply ignores --enable switches it doesn't recognize (another > questionable autoconf design decision, but I digress). And if you are > setting CFLAGS for yourself, you are surely capable of adding -g to it > if you want; why would you type seven times as much to accomplish the > same thing? The discussion mentions the problem with keeping --enable-debug: http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php I am not sure that Peter actually implemented it, but when I started seeing -g flags in the compile, I assumed it had been done. -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Tom Lane wrote: >>> Bruce Momjian <pgman@candle.pha.pa.us> writes: >>> Also, I thought Peter advocated adding -g a few releases back. >> I don't recall any such vote. > The vote was whether -g should be used for a default compile. > Here is the thread discussing the -g flag: > http://archives.postgresql.org/pgsql-hackers/2002-04/msg00281.php 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. regards, tom lane
Tom Lane writes: > 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? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Tom Lane writes: > > > 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. Also, -g bloats the executable, encouraging people/installers to run strip, which removes all symbols. Without -g and without strip, at least we get function names in the backtrace. -- 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, Pennsylvania19073
Bruce Momjian wrote: > Peter Eisentraut wrote: >> Tom Lane writes: >> >> > 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? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Bruce Momjian wrote: > Peter Eisentraut wrote: > > Tom Lane writes: > > > > > 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? It is? kevin@filer:~/tmp$ gcc -c foo.c kevin@filer:~/tmp$ ls -l foo.o -rw-r--r-- 1 kevin kevin 876 Oct 26 18:52 foo.o kevin@filer:~/tmp$ gcc -g -c foo.c kevin@filer:~/tmp$ ls -l foo.o -rw-r--r-- 1 kevin kevin 12984 Oct 26 18:52 foo.o Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs Doesn't look like it to me... If -g is the default, it must be very recent, in which case it's obviously not something for our configuration scripts to rely on. > > 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. I thought --enable-debug had other implications, e.g. enabling assert()s and other such things you might want enabled for debugging but not for production. It certainly makes sense for it to have such semantics even if it doesn't right now. When combined with gcc, -g is, IMO, too useful to eliminate: it makes it possible to get good stacktraces in the face of crashes, and makes it possible to examine variables and such when looking at core files. > Also, -g bloats the executable, encouraging people/installers to run > strip, which removes all symbols. Without -g and without strip, at > least we get function names in the backtrace. This should be up to the individual. I'd argue that disk space is so plentiful and so cheap these days that executable bloat is hardly worth considering. But even if it were, a database tends to be so critical to so many things that you probably want to know why and how it crashes more than you would most other things. So even if you might be inclined to strip most of your binaries, you might think twice about doing the same for the PG binaries. -- Kevin Brown kevin@sysexperts.com
Jan Wieck wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > >> Tom Lane writes: > >> > >> > 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. -- 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, Pennsylvania19073
Kevin Brown wrote: > > > You do realize that as of now, -g is the default for gcc? > > It is? > > kevin@filer:~/tmp$ gcc -c foo.c > kevin@filer:~/tmp$ ls -l foo.o > -rw-r--r-- 1 kevin kevin 876 Oct 26 18:52 foo.o > kevin@filer:~/tmp$ gcc -g -c foo.c > kevin@filer:~/tmp$ ls -l foo.o > -rw-r--r-- 1 kevin kevin 12984 Oct 26 18:52 foo.o > Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs > > > Doesn't look like it to me... He meant for compiling PostgreSQL using gcc, -g is the default, or was until we changed it yesterday. We can't use -g for non-gcc compilers because it often turns off optimization. > > 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. > > I thought --enable-debug had other implications, e.g. enabling assert()s > and other such things you might want enabled for debugging but not for > production. It certainly makes sense for it to have such semantics even > if it doesn't right now. We have --enable-cassert for asserts. Right now I only see:# supply -g if --enable-debugif test "$enable_debug" = yes -a"$ac_cv_prog_cc_g" = yes; then CFLAGS="$CFLAGS -g"fi > When combined with gcc, -g is, IMO, too useful to eliminate: it makes it > possible to get good stacktraces in the face of crashes, and makes it > possible to examine variables and such when looking at core files. If folks want it, they can enable it, and you still get function call names in a backtrace without -g, just not the line numbers. > > Also, -g bloats the executable, encouraging people/installers to run > > strip, which removes all symbols. Without -g and without strip, at > > least we get function names in the backtrace. > > This should be up to the individual. I'd argue that disk space is so > plentiful and so cheap these days that executable bloat is hardly worth > considering. > > But even if it were, a database tends to be so critical to so many > things that you probably want to know why and how it crashes more than > you would most other things. So even if you might be inclined to strip > most of your binaries, you might think twice about doing the same for > the PG binaries. Well, we don't want to use debug for non-gcc (no optimization) so do we do -g for gcc, and then --enable-debug does nothing. Seems people can decide for themselves. -- 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, Pennsylvania19073
Bruce Momjian wrote: > Well, we don't want to use debug for non-gcc (no optimization) so do we > do -g for gcc, and then --enable-debug does nothing. Seems people can > decide for themselves. But doesn't --enable-debug turn off optimization? It's really a question of what the default behavior should be for each option. Clearly for non-gcc compilers, the default should be -O only since they probably can't simultaneously handle -g. But gcc builds are an exception, one which I think is worth considering. Hence my opinion that for gcc builds, the default should be -g and -O. -- Kevin Brown kevin@sysexperts.com
Bruce Momjian wrote: > Jan Wieck wrote: >> Bruce Momjian wrote: >> > Peter Eisentraut wrote: >> >> Tom Lane writes: >> >> >> >> > 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. The other compiler flags like -O are much more important because the out of the box configuration is the one we're allways blamed for. If it's too hard to teach autoconf the difference between gcc and non-gcc, then rip 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 #
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. > The other compiler flags like -O are much more important because the out > of the box configuration is the one we're allways blamed for. If it's > too hard to teach autoconf the difference between gcc and non-gcc, then > rip it. Sure, we can do it, but it is a question of consistency. -- 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, Pennsylvania19073
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, Pennsylvania19073
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 #
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, Pennsylvania19073
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 #