On Tue, Jul 24, 2018 at 12:39 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Tue, Jul 24, 2018 at 12:29:37PM +0200, Tom de Vries wrote:
> > > I wonder if it makes sense to disambiguate things from the gcc side
> > > by generating an empty location description for known optimized out
> > > values (the standard seems to explicitely call that out as a way to
> > > say "optimized out").
>
> You can't emit the empty location descriptions in the middle of other
> expressions though,

True.  We'd have to "fold" any expression dependend on the optimized out
value to optimized out itself.

> and if you have e.g. an expression that uses
> DW_OP_GNU_variable_size only conditionally, even if you know that
> the corresponding DIE doesn't have location, the containing DWARF expression
> could still be well defined if the condition guarding the
> DW_OP_GNU_variable_size isn't true.

DW_OP_GNU_variable_value you mean.  That's true.  But I was talking about
omitting DW_AT_upper_bound which would correspond to int[] vs.
a empty location list DW_AT_upper_bound which would correspond to
int[<something>].
ISTR we quite aggressively prune DW_OP_GNU_variable_values that we cannot
resolve.

> And, also, for DW_OP_GNU_variable_size DIE lookup should be performed,
> say you have only a declaration in the TU, but definition somewhere else,
> in that case the debugger should be using that other TU's definition
> with hopefully location description.  Or if there is a global variable
> interposed by some other TU, again, DW_OP_GNU_variable_size should follow
> to whatever variable wins.

Not sure if that is how it behaves (well, gdb still doesn't support
DW_OP_GNU_variable_value).  Related is probably that I wanted to have
debug info of VLAs in the abstract instance so we'd have a
DW_OP_GNU_variable_value
of a DIE in the abstract instance (with no location) and the concrete instance
DIE of the refered to DIE would only be related to it via its
DW_AT_abstract_origin
attribute.  Ideally that would just work but given lacking gdb support
I couldn't
figure that out and thus we re-emit the whole type in the concrete instances...

If we sort that out we can drop all of the VLA type remapping during
inlining / cloning I think
given we have debug info for the abstract instance around.

Richard.

>
>         Jakub

Reply via email to