Variable values before initialisaton

Variable values before initialisaton

[Rob Quill]

Hi,

Sorry to ask to many questions in one day. but I was wondering fi
anyone could explain why a variable can have a value before it has
been declared.

In my code I have:

int i = 0;
int j = 2;
int k = 3;

and if I print the value of k any time before it has been set to 3, it
get it being equal to a very large number, rather than it not being in
the current scope. Is this a debugging thing, or something to do with
the way the code is compiled, or something else?

Thanks,

Rob

Re: Variable values before initialisaton

[Vladimir Prus]

Rob Quill wrote:

> Hi,
> 
> Sorry to ask to many questions in one day. but I was wondering fi
> anyone could explain why a variable can have a value before it has
> been declared.
> 
> In my code I have:
> 
> int i = 0;
> int j = 2;
> int k = 3;
> 
> and if I print the value of k any time before it has been set to 3, it
> get it being equal to a very large number, rather than it not being in
> the current scope. Is this a debugging thing, or something to do with
> the way the code is compiled, or something else?

You're extremely lucky you've int variables, and not C++ classes, and not
trying to call member functions of those. 

The gdb/gcc combination has the bad habit of including not-yet-created
variables in the list of local variables. I don't think anybody's working
on a fix.

- Volodya

Variable values before initialisaton

[Rob Quill]

How could I go about looking into a fix? I wouldn't really know where
to start, but it is quite annoying for what  am trying to do.

Thanks for your help.

Rob

On 23/11/06, Vladimir Prus <ghost@cs.msu.su> wrote:
> Rob Quill wrote:
>
> > Hi,
> >
> > Sorry to ask to many questions in one day. but I was wondering fi
> > anyone could explain why a variable can have a value before it has
> > been declared.
> >
> > In my code I have:
> >
> > int i = 0;
> > int j = 2;
> > int k = 3;
> >
> > and if I print the value of k any time before it has been set to 3, it
> > get it being equal to a very large number, rather than it not being in
> > the current scope. Is this a debugging thing, or something to do with
> > the way the code is compiled, or something else?
>
> You're extremely lucky you've int variables, and not C++ classes, and not
> trying to call member functions of those.
>
> The gdb/gcc combination has the bad habit of including not-yet-created
> variables in the list of local variables. I don't think anybody's working
> on a fix.
>
> - Volodya
>
>
>

Re: Variable values before initialisaton

[Daniel Jacobowitz]

On Thu, Nov 23, 2006 at 05:32:39PM +0000, Rob Quill wrote:
> How could I go about looking into a fix? I wouldn't really know where
> to start, but it is quite annoying for what  am trying to do.

You have to emit proper debug info from the compiler.  It's the only
thing that knows.  However, for things where initialization is
complicated (like classes), there's basically no way to get it right.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable values before initialisaton

[Rob Quill]

Out of interest why is there no way to get it right? Do you think I
should email the GCC list about it and ask, or do you think it's
wasted effort?

Thanks,
Rob

On 23/11/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Nov 23, 2006 at 05:32:39PM +0000, Rob Quill wrote:
> > How could I go about looking into a fix? I wouldn't really know where
> > to start, but it is quite annoying for what  am trying to do.
>
> You have to emit proper debug info from the compiler.  It's the only
> thing that knows.  However, for things where initialization is
> complicated (like classes), there's basically no way to get it right.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: Variable values before initialisaton

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Thu, Nov 23, 2006 at 05:32:39PM +0000, Rob Quill wrote:
>> How could I go about looking into a fix? I wouldn't really know where
>> to start, but it is quite annoying for what  am trying to do.
> 
> You have to emit proper debug info from the compiler.  It's the only
> thing that knows.  However, for things where initialization is
> complicated (like classes), there's basically no way to get it right.

Can you clarify? Certainly, each constructor invocation produces a finite
number of processor instruction. You can identify the "last" instruction of
those, and hack gcc to produce file last_instructions_of_ctors.txt and make
gdb read such file and do the right thing.

Now getting this work in nice way can be a lot of work, but where does "no
way to get it right" comes from? The only serious complexity I can imagine
is that if body of ctor is duplicated along two execution paths. I doubt
this happens regularly, at least at -O0.

- Volodya

Re: Variable values before initialisaton

[Daniel Jacobowitz]

On Fri, Nov 24, 2006 at 09:52:52AM +0300, Vladimir Prus wrote:
> Can you clarify? Certainly, each constructor invocation produces a finite
> number of processor instruction. You can identify the "last" instruction of
> those, and hack gcc to produce file last_instructions_of_ctors.txt and make
> gdb read such file and do the right thing.

You can have:

  - Initialize part A of structure
  - Read part A of structure
  - Initialize rest of structure

You don't want GDB to be unable to display the structure at that read,
do you?  So you need to know which bits of it are initialized and which
aren't.  And, in some cases, you want to be able to debug a structure
pointer after "new" returns some storage but before the constructor is
invoked.

I suppose this is doable though: a very interesting project for someone
interested in learning about debug info formats and generation would be
to annotate initializedness somehow.  The compiler does know.  But it
wouldn't be easy.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Variable values before initialisaton

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Fri, Nov 24, 2006 at 09:52:52AM +0300, Vladimir Prus wrote:
>> Can you clarify? Certainly, each constructor invocation produces a finite
>> number of processor instruction. You can identify the "last" instruction of
>> those, and hack gcc to produce file last_instructions_of_ctors.txt and make
>> gdb read such file and do the right thing.
>
> You can have:
>
>   - Initialize part A of structure
>   - Read part A of structure
>   - Initialize rest of structure
>
> You don't want GDB to be unable to display the structure at that read,
> do you?  So you need to know which bits of it are initialized and which
> aren't.  And, in some cases, you want to be able to debug a structure
> pointer after "new" returns some storage but before the constructor is
> invoked.
>
> I suppose this is doable though: a very interesting project for someone
> interested in learning about debug info formats and generation would be
> to annotate initializedness somehow.  The compiler does know.  But it
> wouldn't be easy.

I think this is a bit afield from Rob's original question.  In the
code he posted:

    int i = 0;
    int j = 2;
    int k = 3;

the issue isn't initialization.  Rather it's that the scope of k
doesn't include the declarations of i and j, but GCC collapses all
these declarations into one block, so GDB thinks k's scope does
include the first two lines.  If GCC produced DW_AT_start_scope
attributes (p. 61, #11 in DWARF 3), and GDB understood them, then this
would work.

Re: Variable values before initialisaton

[Rob Quill]

On 27/11/06, Jim Blandy <jimb@codesourcery.com> wrote:
>
> Daniel Jacobowitz <drow@false.org> writes:
> > On Fri, Nov 24, 2006 at 09:52:52AM +0300, Vladimir Prus wrote:
> >> Can you clarify? Certainly, each constructor invocation produces a finite
> >> number of processor instruction. You can identify the "last" instruction of
> >> those, and hack gcc to produce file last_instructions_of_ctors.txt and make
> >> gdb read such file and do the right thing.
> >
> > You can have:
> >
> >   - Initialize part A of structure
> >   - Read part A of structure
> >   - Initialize rest of structure
> >
> > You don't want GDB to be unable to display the structure at that read,
> > do you?  So you need to know which bits of it are initialized and which
> > aren't.  And, in some cases, you want to be able to debug a structure
> > pointer after "new" returns some storage but before the constructor is
> > invoked.
> >
> > I suppose this is doable though: a very interesting project for someone
> > interested in learning about debug info formats and generation would be
> > to annotate initializedness somehow.  The compiler does know.  But it
> > wouldn't be easy.
>
> I think this is a bit afield from Rob's original question.  In the
> code he posted:
>
>     int i = 0;
>     int j = 2;
>     int k = 3;
>
> the issue isn't initialization.  Rather it's that the scope of k
> doesn't include the declarations of i and j, but GCC collapses all
> these declarations into one block, so GDB thinks k's scope does
> include the first two lines.  If GCC produced DW_AT_start_scope
> attributes (p. 61, #11 in DWARF 3), and GDB understood them, then this
> would work.
>

Interesting. Is it that GCC doesn't implement it, or that GDB doesn't
understand it, or both? How difficult to you think it would be to
implement, because I think it would be quite good to have it right.

Thanks,
Rob

Re: Variable values before initialisaton

[Jim Blandy]

"Rob Quill" <rob.quill@gmail.com> writes:
> Interesting. Is it that GCC doesn't implement it, or that GDB doesn't
> understand it, or both? How difficult to you think it would be to
> implement, because I think it would be quite good to have it right.

Neither GCC nor GDB emit DW_AT_start_scope.  I don't know about GCC,
but it would be somewhat involved in GDB; you'd have to change
read_lexical_block_scope in dwarf2read.c to produce a bunch of nested
blocks.

I'm gathering from your comments that the you've been assuming that
GCC + DWARF + GDB present an accurate model of the execution of the
source program.  But the only (significant to development) consumer of
the model we actually present has been humans and the test suite, so
little issues like this haven't been tended to very carefully, since
humans don't mind them.  I don't want to discourage you, but I think
you'll find more as you go along, and some may be a lot of work to
fix.