This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [C++] static data members, gdb problems with
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: [C++] static data members, gdb problems with
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Wed, 30 Aug 2000 22:54:42 -0700 (PDT)
- cc: gcc at gcc dot gnu dot org, bug-gdb at gnu dot org
Not our fault, the debug info is wrong, or it really is optimized out.
It doesn't give us either a bit offset, or the data member location inside
the struct, or a place where we can find them.
So GDB, rightfully, assumed it's optimized out (because it has no
location, and thus, doesn't exist).
It happens with both dwarf2 and stabs.
Modify the test case slightly to prove a point:
struct __ios_flags
{
typedef short __int_type;
static const __int_type _S_boolalpha = 1;
int hasALocation;
};
With dwarf2, I see:
<2><6d>: Abbrev Number: 3 (DW_TAG_variable)
DW_AT_name : _S_boolalpha
DW_AT_decl_file : 1
DW_AT_decl_line : 4
DW_AT_MIPS_linkage_name: _11__ios_flags._S_boolalpha
DW_AT_type : <17c>
DW_AT_external : 1
DW_AT_declaration : 1
<2><9f>: Abbrev Number: 4 (DW_TAG_member)
DW_AT_name : hasALocation
DW_AT_decl_file : 1
DW_AT_decl_line : 5
DW_AT_type : <18e>
DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
Hmm, this implies hasALocation is the first member of the struct.
As if it really was being optimized out.
Time to check the assembly.
with gcc 2.95.2
g++ -save-temps -O0 -gdwarf-2 b.cc
<useless info and labels removed>
main:
pushl %ebp
movl %esp,%ebp
subl $24,%esp
movl $1,-8(%ebp)
xorl %eax,%eax
jmp .L2
xorl %eax,%eax
jmp .L2
.p2align 4,,7
.L2:
leave
ret
Yup, it really was optimized out.
With the latest gcc, it's even simpler code.
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl $1, -8(%ebp)
movl $0, %eax
movl %ebp, %esp
popl %ebp
ret
In short, gdb's right.
If this is a problem, talk to the gcc guys about not optimizing this when
-O0 is on.
--Dan
On Wed, 30 Aug 2000, Benjamin Kosnik wrote:
>
> I'm having some problems with static data members and gdb. (This would
> be current sourceware GDB, via the 'src' repository on RH 6.2/x86)
>
> To get the ball rolling, I've made a simple test case:
>
>
> struct __ios_flags
> {
> typedef short __int_type;
> static const __int_type _S_boolalpha = 1;
> };
>
> int main()
> {
> __ios_flags obj; // p obj::_S_boolalpha
> int i = __ios_flags::_S_boolalpha;
> return 0;
> }
>
>
> (gdb) p __ios_flags::_S_boolalpha
> Internal error: could not find static variable _S_boolalpha
> (gdb) p i
> $1 = 1
> (gdb) p obj
> $2 = {static _S_boolalpha = <optimized out>}
> (gdb)
>
> This is showing just one problem: most often, I see cases where gdb
> says things like: can't display result 0x0000...
>
> anyway.
>
> -benjamin
>
>
>
>