Re: [g++] cannot debug static const data members

[Benjamin Kosnik <bkoz at redhat dot com>]

> > (or even hard) way for me to tell what static const data members in a
> > given abstract data type have not been defined, or which ones have
> > definitions that cannot be found, or some other voodoo or spell
> > casting I can do to make this work?
> 
> It is almost working.
> 
> 0x62 = 98
> 
> In other words, it's got the right value, but it thinks it's a memory 
> address, rather than a constant value.
> I'll explore it further.

Please let me know what you find. Here's a bit more information I found, 
it may be helpful to you.

In my followup, I posted this:

Talking to myself:

Of the following symbols, the only one I can see in gdb is string's npos 
(the 2nd one)

/mnt/hd/ahimsa/bld-x86-gcc-debug/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
%nm locale.o |grep none
00003f60 t _GLOBAL_.I._ZNSt6locale4noneE
00000000 R _ZNSt6locale4noneE

/mnt/hd/ahimsa/bld-x86-gcc-debug/i686-pc-linux-gnu/libstdc++-v3/src/.libs
%nm string-inst.o |grep npos
00000000 V _ZNSs4nposE

/mnt/hd/ahimsa/bld-x86-gcc-debug/i686-pc-linux-gnu/libstdc++-v3/src/.libs
%nm ios.o |grep _S_dec
00000002 R _ZNSt11__ios_flags6_S_decE

I see no reason why these symbols should be in different sections. 
Clearly, they are all static const data members, and should all be in R, 
a read-only location (not weak == V). Am I missing something, or is this a 
compiler bug?

Of course, this will probably break debugging string again, oh well...

> I've got patches that are almost ready to be submitted that fix all of 
> this. It's about 50-1000x faster on large C++ apps, no joke. It also 
> makes it trivial for me to reduce memory usage by a larrge factor when i 
> get a chance.

Ok. Sounds promising. Can you make sure you send a note to the 
libstdc++@gcc.gnu.org when your patches make it in so that we can try it 
out? I don't often peruse the gdb CVS commit lists.

Debuggable C++ is more important to me than sane error messages, FWIW.

> However, it only works with dwarf2, as stabs doesn't give us the info we 
> need (in the debug info, A::q appears inside main, and is marked as 
> external, which lets me know that it's not really a local.)

... I think everybody is using dwarf2 for c++ debugging anyway. It's 
explicitly written into the libstdc++-v3 Makefiles for --enable-debug. I 
don't really consider 
this a huge stumbling block. In fact, if I were given the option of using 
a dwarf2-gdb that worked for c++, even if was a fork from mainline gdb, I 
would use it. 

Give me the wheel........ I've mastered the inclined plane.

-benjamin