Re: Patch - Debug builds without optimization

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch - Debug builds without optimization
Date: 2011-06-16 15:04:04
Message-ID: 4DFA1B64.2030906@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Browne 2011-06-16 15:15:50 Re: pg_upgrade using appname to lock out other users
Previous Message Florian Pflug 2011-06-16 14:49:53 Re: Re: Latch implementation that wakes on postmaster death on both win32 and Unix