"info locals" -- is variable initialized

"info locals" -- is variable initialized

[Vladimir Prus]

Hello,
I'm thinking about adding pretty-printing for STL and KDE structures in
KDevelop, and run into this problem. Consider the program:

   int main()
   {
        int i1;
        ....
        KURL i2;
   }

When entering this function, KDevelop asks gdb via "info locals" what locals
vars are there. But, gdb reports all variables, even though at the function
entry 'i2' is not initialized (or, from C++ point of view, not even visible
yet). For pretty priting 'i2', I have to evaluate 'i2.prettyURL(0)', which
will just crash. I can use "set unwindonsignal on", but generally, calling
methods on uninitialized object can damage random memory.

So:
1. Can I determine, for a given variable, if it's in scope already?
2. Can I make "info local" return only the variables that are already in
scope?
3. If no, any ideas how the above can be implemented?

- Volodya

Re: "info locals" -- is variable initialized

[Ramana Radhakrishnan]

> 
> When entering this function, KDevelop asks gdb via "info locals" what locals
> vars are there. But, gdb reports all variables, even though at the function
> entry 'i2' is not initialized (or, from C++ point of view, not even visible
> yet). For pretty priting 'i2', I have to evaluate 'i2.prettyURL(0)', which
> will just crash. I can use "set unwindonsignal on", but generally, calling
> methods on uninitialized object can damage random memory.

GDB puts a breakpoint after the prologue of a function. Which means that
all locals in scope have been created / allocated space for . Hence you
would see i2 , right ?

cheers
Ramana

Re: "info locals" -- is variable initialized

[Vladimir Prus]

Ramana Radhakrishnan wrote:

> 
>> 
>> When entering this function, KDevelop asks gdb via "info locals" what
>> locals vars are there. But, gdb reports all variables, even though at the
>> function entry 'i2' is not initialized (or, from C++ point of view, not
>> even visible yet). For pretty priting 'i2', I have to evaluate
>> 'i2.prettyURL(0)', which will just crash. I can use "set unwindonsignal
>> on", but generally, calling methods on uninitialized object can damage
>> random memory.
> 
> GDB puts a breakpoint after the prologue of a function. Which means that
> all locals in scope have been created / allocated space for . Hence you
> would see i2 , right ?

Wrong, I think. Function progolue only allocates space for KURL, but does
not call the constructor.

Consider:
int main()
{
    int i = 10;
    std::vector<int> v2;
    KURL url = "http://boost.org";
}


And assembler of it:
0x080487f4 <main+0>:    push   %ebp
0x080487f5 <main+1>:    mov    %esp,%ebp
0x080487f7 <main+3>:    push   %ebx
0x080487f8 <main+4>:    sub    $0x84,%esp
0x080487fe <main+10>:   and    $0xfffffff0,%esp
0x08048801 <main+13>:   mov    $0x0,%eax
0x08048806 <main+18>:   sub    %eax,%esp

<gdb sets breakpoint on the following instruction>

0x08048808 <main+20>:   movl   $0xa,0xfffffff4(%ebp)

<initialization of vector starts here>

0x0804880f <main+27>:   lea    0xffffffc8(%ebp),%eax
0x08048812 <main+30>:   mov    %eax,(%esp)
0x08048815 <main+33>:   call   0x8048924 <allocator>
0x0804881a <main+38>:   lea    0xffffffc8(%ebp),%eax
0x0804881d <main+41>:   mov    %eax,0x4(%esp)
0x08048821 <main+45>:   lea    0xffffffd8(%ebp),%eax
0x08048824 <main+48>:   mov    %eax,(%esp)
0x08048827 <main+51>:   call   0x80489a0 <vector>
...........

and only here std::vector is initialized.

So, there's a window there variable does not exists according to C++, but
exists according to gdb. 

- Volodya

Re: "info locals" -- is variable initialized

[Daniel Jacobowitz]

On Fri, Sep 02, 2005 at 01:53:41PM +0400, Vladimir Prus wrote:
> So, there's a window there variable does not exists according to C++, but
> exists according to gdb. 

With better debug information, this doesn't happen (or the window is
reduced to an instruction or two in the call sequence for the
constructor).  GCC 4's variable tracking feature does this passably
well, IIRC, by use of dwarf2 location lists.

In general no there is nothing gdb can do.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: "info locals" -- is variable initialized

[Vladimir Prus]

On Friday 02 September 2005 17:13, Daniel Jacobowitz wrote:
> On Fri, Sep 02, 2005 at 01:53:41PM +0400, Vladimir Prus wrote:
> > So, there's a window there variable does not exists according to C++, but
> > exists according to gdb.
>
> With better debug information, this doesn't happen (or the window is
> reduced to an instruction or two in the call sequence for the
> constructor).  GCC 4's variable tracking feature does this passably
> well, IIRC, by use of dwarf2 location lists.

Do I need for extra flags for gcc? I've tried with gcc-4.0 before posting the
message, and it did printed all vars.

> In general no there is nothing gdb can do.

How about using decl_line. Here's what debug info says

   <2><2188c>: Abbrev Number: 140 (DW_TAG_variable)
     DW_AT_name        : url
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 14
     DW_AT_type        : <1d555>
     DW_AT_location    : 3 byte block: 91 98 7f         (DW_OP_fbreg: -104)

If gdb could tell the value of 'decl_line' via some command, that might be a 
good approximation.

- Volodya

Re: "info locals" -- is variable initialized

[Daniel Jacobowitz]

On Fri, Sep 02, 2005 at 05:18:46PM +0400, Vladimir Prus wrote:
> On Friday 02 September 2005 17:13, Daniel Jacobowitz wrote:
> > On Fri, Sep 02, 2005 at 01:53:41PM +0400, Vladimir Prus wrote:
> > > So, there's a window there variable does not exists according to C++, but
> > > exists according to gdb.
> >
> > With better debug information, this doesn't happen (or the window is
> > reduced to an instruction or two in the call sequence for the
> > constructor).  GCC 4's variable tracking feature does this passably
> > well, IIRC, by use of dwarf2 location lists.
> 
> Do I need for extra flags for gcc? I've tried with gcc-4.0 before posting the
> message, and it did printed all vars.

I think it's activated with optimization, but with -O0 you may need
-fvar-tracking.  I don't know for sure.

> > In general no there is nothing gdb can do.
> 
> How about using decl_line. Here's what debug info says
> 
>    <2><2188c>: Abbrev Number: 140 (DW_TAG_variable)
>      DW_AT_name        : url
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 14
>      DW_AT_type        : <1d555>
>      DW_AT_location    : 3 byte block: 91 98 7f         (DW_OP_fbreg: -104)
> 
> If gdb could tell the value of 'decl_line' via some command, that might be a 
> good approximation.

Using line numbers for this sort of thing is really not a good idea. 
They're useful for displaying source to the user, but for anything
else, there are too many potential strangenesses...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: "info locals" -- is variable initialized

[Vladimir Prus]

On Friday 02 September 2005 17:20, Daniel Jacobowitz wrote:
> On Fri, Sep 02, 2005 at 05:18:46PM +0400, Vladimir Prus wrote:
> > On Friday 02 September 2005 17:13, Daniel Jacobowitz wrote:
> > > On Fri, Sep 02, 2005 at 01:53:41PM +0400, Vladimir Prus wrote:
> > > > So, there's a window there variable does not exists according to C++,
> > > > but exists according to gdb.
> > >
> > > With better debug information, this doesn't happen (or the window is
> > > reduced to an instruction or two in the call sequence for the
> > > constructor).  GCC 4's variable tracking feature does this passably
> > > well, IIRC, by use of dwarf2 location lists.
> >
> > Do I need for extra flags for gcc? I've tried with gcc-4.0 before posting
> > the message, and it did printed all vars.
>
> I think it's activated with optimization, but with -O0 you may need
> -fvar-tracking.  I don't know for sure.

-fvar-tracking is accepted, but does not have any result on "info locals".

> > > In general no there is nothing gdb can do.
> >
> > How about using decl_line. Here's what debug info says
> >
> >    <2><2188c>: Abbrev Number: 140 (DW_TAG_variable)
> >      DW_AT_name        : url
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 14
> >      DW_AT_type        : <1d555>
> >      DW_AT_location    : 3 byte block: 91 98 7f         (DW_OP_fbreg:
> > -104)
> >
> > If gdb could tell the value of 'decl_line' via some command, that might
> > be a good approximation.
>
> Using line numbers for this sort of thing is really not a good idea.
> They're useful for displaying source to the user, but for anything
> else, there are too many potential strangenesses...

I realize, but given that no better mechanism exist, what can I do?

- Volodya