This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix internal error on optimized-out values (regression by me)
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Tom Tromey <tromey at redhat dot com>
- Date: Mon, 10 Oct 2011 22:40:28 +0100
- Subject: Re: [patch] Fix internal error on optimized-out values (regression by me)
- References: <20110926191132.GA30401@host1.jankratochvil.net> <m3k48lswcn.fsf@fleche.redhat.com> <20111010205407.GA5193@host1.jankratochvil.net>
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