[PATCH] D35994: Debug info for variables whose type is shrinked to bool

[David Blaikie via llvm-commits]

On Mon, Aug 28, 2017 at 9:21 AM Nikola Prica via Phabricator <
reviews at reviews.llvm.org> wrote:

> NikolaPrica marked an inline comment as done.
> NikolaPrica added a comment.
>
> >>
> >>
> >>   val * (ValOther - ValInit) + ValInit:
> >
> > If we are doing this expression, there should be an assertion in the
> code that `ValInit < ValOther`.
>
> I have tested this for edge cases such as both negative values, LONG_MAX,
> LONG_INT etc and there was no problem for this values. Only flaw for this
> is ugly long DW_AT_location expression for long values.
>
> >>    DW_OP_deref DW_OP_constu <ValMinus>
> >>   DW_OP_mul DW_OP_constu <ValInit> DW_OP_plus DW_OP_stack_value
> >
> > Why does `Val` need to be dereferenced?
>
> DW_OP_deref needs to be used because we have address of new variable on
> stack, not its value.
>
> > Apart from the DW_OP_deref, this seems very good, I'm slightly worried
> about the assumption that the init value will always be the smaller one.
> >  What happens if any of the two values is negative (because of the
> typeless DWARF <5 expression stack — not sure if this will be a problem).
>
> For dwarf versions lower than 4 gdb reads value of DW_AT_location
> expression as address giving message "Cannot access memory at address
> 0x1e". This may be a problem but it is still better than optimized-out?
>

I'm a bit curious about this - are the DW_OPs we're using defined in DWARF
lower than 4? If not, what do we want to do about that? I know we've
historically supported older DWARF versions on a sort of ad-hoc as-needed
basis, so breaking this might not be out of character there...

But I'm kind of OK saying "optimized out" if there's no way to express the
location in the DWARF version the user asked for... (so perhaps when
emitting the expression in the backend, we could check the supported
version for the ops being used, and drop the whole location if any of the
ops aren't supported by the version being emitted)

- Dave


>
>
> https://reviews.llvm.org/D35994
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170828/433f8d94/attachment.html>