Re: Patch - Debug builds without optimization

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch - Debug builds without optimization
Date: 2011-11-29 21:32:42
Message-ID: 201111292132.pATLWgI21684@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me know if you want additional text.

---------------------------------------------------------------------------

Greg Smith wrote:
> On 06/16/2011 10:10 AM, Tom Lane wrote:
> > I could see providing some other nonstandard configure switch that
> > changed the default -O level ... but realistically, would that do
> > anything that you couldn't already do by setting CFLAGS, ie
> >
> > ./configure CFLAGS="-O0 -g"
> >
>
> I think a small discussion of the issue Radek ran into is appropriate to
> put somewhere, with this example. The install procedure section of the
> docs already includes a CFLAGS example:
>
> ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
>
> There is also a section talking about setting options like
> --enable-cassert in the Developer's FAQ. Looking at all the info out
> there about developer/debug builds, it's really kind of sketchy and
> distributed though. No one place that pulls all the most common things
> people need together into one resource.
>
> What seems like the idea solution here is to add a new section to the
> install procedure with brief coverage of this entire area. Here's a
> prototype of text that might go there:
>
> = Installation for development and debugging =
>
> When modifying the PostgreSQL source code, or when trying to find the
> source of a bug in the program, it may be helpful to build the program
> in a way that makes this process easier. There are build-time only
> changes that enable better error checking and debugging, including:
>
> Pass --enable-cassert to configure. This can make bugs more visible,
> because they cause operations to abort with a clear error. That makes
> some types of debugging much easier. This is risky on a production
> server, as described in the documentation for this parameter.
>
> Pass --enable-debug to configure. This provides better information about
> what the server is doing when looking at it using a debugger. It's less
> risky to a production server than enabling assertions, and it normally
> has less of a performance impact hgtoo. See its documentation for more
> details.
>
> Disable compiler optimization. When using a debugger to trace into the
> source code of the server, steps may optimized away by the normal build
> process. In some situations --enable-debug will disable such
> optimization, but this is not always the case. Specifically disabling
> optimization is possible with many compilers by setting the compiler
> flags when configuration the source code build, such as:
>
> ./configure CFLAGS="-O0 -g"
>
> This example for the gcc compiler disables optimizations, and tells the
> compiler to provide extra debugging information most useful with the gdb
> debugger.
>
> --
> Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Attachment Content-Type Size
/rtmp/doc text/x-diff 711 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-11-29 21:35:18 Re: Allow pg_dumpall to use dumpmem.c functions, simplify exit code
Previous Message Brar Piening 2011-11-29 21:32:01 Re: Review of VS 2010 support patches