llvm dev - Jun 2007 - [LLVMdev] Fun with _GLIBCXX_DEBUG

So far we've tracked down four bugs using _GLIBCXX_DEBUG, all of them quite 
subtle and some of them leading to serious problems like heap corruption.

But we've also discovered that compile time can skyrocket in some cases as
the
library does its checks. The standard library complexity guarantees don't 
apply with _GLIBCXX_DEBUG.

Therefore, we should figure out if we want to enable this in debug builds by 
default, include a configure option for it or create some new target 
(Developer?) that does a build that includes it.

Builds of llvm and llvm-gcc must be consistent in their use of _GLIBCXX_DEBUG.
That implies that any change to llvm in this respect must be reflected in 
llvm-gcc. Consequently, we're going to have a timing issue with any change
to
llvm to make sure both repositories get updated correctly and don't cause 
trouble for people.

In my local copy of llvm-gcc _GLIBCXX_DEBUG is turned on by --enable-checking.

So here are the questions we should wrestle with before making any changes:

- Do we want _GLIBCXX_DEBUG enabled in debug builds by default?

- Should it be a configure option?

- Should we create a new kind of build to include it?

- What's the strategy for llvm-gcc?

If we want to make this change, I can either submit patches to llvm-gcc or 
someone can give me commit access.  I don't care which it is, pick the one 
that's most convenient for everyone.  I'm make the changes to llvm
myself,
one per bugfix and then the inclusion of _GLIBCXX_DEBUG if we decide to
go ahead with it.

This should probably happen after the subversion migration, though I may
commit some bugfixes before that.  It would be helpful to have a more
precise projection of when the conversion will happen.

                                                   -Dave

On Fri, 8 Jun 2007, David A. Greene wrote:
> So far we've tracked down four bugs using _GLIBCXX_DEBUG, all of them
quite
> subtle and some of them leading to serious problems like heap corruption.
Ooh, subtle bugs found and fixed are definitely good.
> But we've also discovered that compile time can skyrocket in some cases
as the
> library does its checks. The standard library complexity guarantees
don't
> apply with _GLIBCXX_DEBUG.
Ah, ok.
> Therefore, we should figure out if we want to enable this in debug builds
by
> default, include a configure option for it or create some new target
> (Developer?) that does a build that includes it.
No, I don't think we do.  I think a configure option is best.
> Builds of llvm and llvm-gcc must be consistent in their use of
_GLIBCXX_DEBUG.
> That implies that any change to llvm in this respect must be reflected in
> llvm-gcc. Consequently, we're going to have a timing issue with any
change to
> llvm to make sure both repositories get updated correctly and don't
cause
> trouble for people.
Okay.  I think the right way to do this is to make it a configure option 
when building LLVM.  Then make sure the option gets propagated down and 
shows up in the "llvm-config --cflags" option.

Once that is done, clients of the LLVM libs can know to build with the 
option.  The next step is to switch llvm-gcc to actually use llvm-config 
--cflags.  Basically change this line:

CPPFLAGS = @CPPFLAGS@ -DENABLE_LLVM -D__STDC_LIMIT_MACROS

to be:

CPPFLAGS := @CPPFLAGS@ -DENABLE_LLVM $(shell $(LLVMBINPATH)/llvm-config
--cflags)

Something close to that should work.
> So here are the questions we should wrestle with before making any changes:
> - Do we want _GLIBCXX_DEBUG enabled in debug builds by default?
Nope
> - Should it be a configure option?
Yep!
> - Should we create a new kind of build to include it?
Probably just a configure option on the llvm libs.
> - What's the strategy for llvm-gcc?
llvm-gcc should transparently follow the llvm libraries.
> If we want to make this change, I can either submit patches to llvm-gcc or
> someone can give me commit access.  I don't care which it is, pick the
one
> that's most convenient for everyone.  I'm make the changes to llvm
myself,
> one per bugfix and then the inclusion of _GLIBCXX_DEBUG if we decide to
> go ahead with it.
For now, please prepare a patch and send it to llvm-commits.  Thanks for 
working on this!
> This should probably happen after the subversion migration, though I may
> commit some bugfixes before that.  It would be helpful to have a more
> precise projection of when the conversion will happen.
I don't think this needs to be tied to the svn migration,

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/