Re: Open items
От | Bruce Momjian |
---|---|
Тема | Re: Open items |
Дата | |
Msg-id | 200310281400.h9SE0QN20149@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Open items (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Open items
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > Have gcc use -g, add --disable-debug, rename? > > > > Personally I don't like the idea of this behavior defaulting differently > > depending on which compiler you use. I can see the practical arguments > > for doing so, but it still rubs me the wrong way. Can anyone offer new > > arguments pro or con here? > > You and I think don't like the inconsistency, while Jan likes the debug > where ever possible (gcc). There were a few others who liked the debug > for gcc by default. > > I think if folks are debugging, they probably should turn off > optimization anyway to make sense of the output, and we are never going > to ship without optimization. What might be nice would be for > --enable-debug to turn off optimization as well so people can actually > make sense of the code in the debugger. > > Basically, I don't like the debug because of: > > inconsistency with non-gcc > binary bloat > binary bloat encourages strip, which is really bad > > Usually function names are enough for us to take a guess on the cause. I think I have a compromise for --enable-debug: How about if --enable-debug removes optimization, adds -g (or -g3 for macro debugging symbols in gcc), and maybe even enables casserts. That way, --enable-debug gives us a super-debuggable binary that we would never ship by default. Also, I can add a section to the release notes that discourages people running 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
В списке pgsql-hackers по дате отправления: