[g++] cannot debug static const data members

Daniel Berlin dberlin@cygnus.com
Fri Dec 22 11:02:00 GMT 2000


On Fri, 22 Dec 2000, Benjamin Kosnik wrote:

> 
> I've been pleasantly surprised with the recent and newly-found ability
> to debug c++ code produced with g++ in gdb. Thanks guys. I know Jason
> and Richard have done work on this lately.
> 
> example: I can now see a std::string in gdb.
> 
> source:
>   std::string s01("touch of evil");
> 
> gdb:
> $1 = {static npos = 4294967295, 
>   _M_dataplus = {<allocator<char>> = {<No data fields>}, 
>     _M_p = 0x80dca9c "touch of evil"}, static _S_empty_rep_storage = {0, 0, 3, 
>     0}}
> 
> awesome!!!!
> 
> Anyway. Now I'm moving on to bigger and badder data types (say,
> std::locale), and am running into a problem seeing static data
> members. Here's a brief, very brief example:
> 
> // start
> class __ios_flags 
> {
>   typedef short __int_type;
> public:
>   static const __int_type _S_dec = 98;
> };
> 
> const __ios_flags::__int_type __ios_flags::_S_dec;
> 
> int main()
> {
>   return 0; // (gdb) p __ios_flags::_S_dec
> }
> // end
> 
> 
> gives, with gdb-5 and current CVS g++:
> 
> (gdb) p __ios_flags::_S_dec
> Cannot access memory at address 0x62
> 
> What gives?? Am I a fool for expecting this to work

no.
>? Is there an easy
> (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.
 > 
> -benjamin
> 
> FYI current gdb is a regression on gdb 5 WRT debugging c++
> 

Yes, in more ways than one. I am working on this.
It's mainly because of afallout trying to move C++ to a binary search, 
rather than linear search.

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.


I've also got a patch that fixes the problem of not being able to do 
something liek this:


namespace A
{
	int q;
}

int main(void)
{
	using A::q;

	q=5;
}


in GDB, print q, in main, won't work.
you'd have to use print A::q.
I've got a patch that makes it work as it should (IE print q in main, 
print A::q anywhere).
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.)
--Dan



More information about the Gcc-bugs mailing list