Re: [patch] Fix internal error on optimized-out values (regression by me)

[Pedro Alves <pedro@codesourcery.com>]

On Monday 10 October 2011 21:54:08, Jan Kratochvil wrote:
> On Mon, 03 Oct 2011 21:34:16 +0200, Tom Tromey wrote:
> > >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> > 
> > Jan> ((struct) <optimized out>).field should be IMO still <optimized
> > Jan> out>; just it became internal-error now.
> > 
> > Maybe I am misunderstanding what you are saying -- I think this should
> > also throw.  I think the rule should be that any attempt to access any
> > "invalid" contents of a value, for purposes of computation, should throw
> > an exception.
> 
> Here is problematic the term "for purposes of computation".
> 
> I agree that any computation with content of <optimized out> must throw.
> 
> But here the content is not interpreted in any way.  Only a smaller subset of
> it is used.
> 
> 
> But I do not have any argument why the former <optimized out> value is better
> than this "value has been optimized out", unaware if there is a precedent for
> either way in current codebase.  Changed it as you suggest.

IMO, this is just like "p s.f", printing <unavailable> when the whole 
of `s' is unavailable.  From the unavailable.exp test:

print globalstruct.memberf
$7 = <unavailable>
(gdb) PASS: gdb.trace/unavailable.exp: collect globals: print globalstruct.memberf
print globalstruct.memberd
print globalstruct
$9 = {memberc = <unavailable>, memberi = <unavailable>, memberf = <unavailable>, memberd = <unavailable>}

It just happens that today, we only support either wholy
optimized-out values, or wholly not optimized-out values.  A
compiler can flatten out structures and optimize out just some
unused fields (of local vars, most usefully).  When
we get to support that, it'll follow naturally that a single
optimized out flag per value isn't sufficient, and that
((struct) <optimized out>).field will need to be able to
be <optimized out>.

-- 
Pedro Alves