Variable values before initialisaton

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

Daniel Jacobowitz <drowfalse.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.

On 27/11/06, Jim Blandy <jimbcodesourcery.com> wrote:
>
> Daniel Jacobowitz <drowfalse.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

"Rob Quill" <rob.quillgmail.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.