[LLVMdev] Fun with _GLIBCXX_DEBUG

Chris Lattner sabre at nondot.org
Sun Jun 10 16:20:59 PDT 2007


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/



More information about the llvm-dev mailing list