[PATCH] D20147: [WIP] DebugInfo: New metadata representation for global variables.

[Adrian Prantl via llvm-commits]

aprantl added a comment.

In http://reviews.llvm.org/D20147#427547, @pcc wrote:

> In http://reviews.llvm.org/D20147#427470, @aprantl wrote:
>
> > In http://reviews.llvm.org/D20147#427453, @pcc wrote:
> >
> > > > Instead of baking a byte-offset into the IR, I was more thinking of using the DIExpression to describe the offset:
> > >
> > >
> > > I suppose we could do that, but I reckon that would make things more complicated:
> > >
> > > - each constant would need two DIExpressions, one for the case where a global exists and an address can be derived from the attached GlobalVariable's address, and one for the case where the global has been optimized away (where we'd use DW_OP_stack_value to describe the constant)
> >
> >
> > Not sure if I follow. While the constant still exists as a global in the IR, the DIExpression would be empty.
> >  Whenever a constant is deleted from IR, we invoke a utility that
> >
> > - adds the DIGlobalVariable to the DICompileUnit to retain it
>
>
> I'm not changing the relationship between DICompileUnit and DIGlobalVariable in this patch. This means that if we change the DIExpression, we'd most likely need to find the DIGlobalVariable in the DICompileUnit's global list and rewrite it. But I suppose that's fine if it's temporary.


Agreed, that sounds not so great. Would it be possible to change the relationship before landing this patch?

> 

> 

> > - translates the constexpr into a DIExpression This is assuming that after GlobalMerge happened no merged globals will be removed.

> 

> 

> Okay. So if I follow you, the interpretation of the DIExpression will change depending on whether the DIGlobalVariable was attached to a GlobalVariable. If it is attached, we'd start with the address of the GlobalVariable on the stack, and if it isn't attached we'd start with an empty stack. Is that what you had in mind?


The DIExpressions in LLVM IR have an implicit first element that is the "base" location of the entity that is being described. The DWARF backend can make the following decision:

- if the DIGlobalVariable is found via a !dbg attachment on a global, the address of the global is emitted as the first element of the dwarf expression, followed by the DIExpression,
- if the DIExpression describes a constant (i.e., it ends with DW_OP_stack_value, DW_OP_implicit_value, DW_OP_implicit_pointer, ...) the DIExpression is emitted as is.

> 

> 

> > > - it would add complexity to the `copyMetadata` function, as it would need to be able to manipulate and rewrite DIExpressions

> 

> > 

> 

> > 

> 

> > Can you give a quick example for this?

> 

> 

> Well, okay, I suppose that if we're just adding an offset it wouldn't be too hard to append (DW_OP_constu, X, DW_OP_plus) to the DIExpression. But we'd (yes, temporarily) need to rewrite the DICompileUnit's global list, and each new kind of metadata node that we attach to globals would require its own handling.


Nitpick: I think it would need to prepend the DW_OP_constu, X, DW_OP_plus.


http://reviews.llvm.org/D20147