This is an archive of the discontinued LLVM Phabricator instance.

[Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer.
AbandonedPublic

Authored by alok on Jul 18 2020, 4:58 PM.

Details

Summary
This patch stems from D84112.
New dwarf operator DW_OP_LLVM_explicit_pointer is introduced (present only in LLVM IR)

DWARF operator DW_OP_implicit_pointer has some limitations like it should appear only in
beginning and there should be only one operator in expression. This is good for ultimate
dump of dwarf in object file. In case of IR we need more freedom to get rid of limitations, to
cater this the new LLVM-IR level operator DW_OP_LLVM_explicit_pointer is introduced, which
can appear at multiple times to support multilevel-indirection (when intermediate level
variables are not user-defined). This IR level operator is finally translated to DWARF operator
DW_OP_implicit_pointer using artificial variables.

Diff Detail

Event Timeline

alok created this revision.Jul 18 2020, 4:58 PM
jmorse added a subscriber: jmorse.Jul 30 2020, 5:39 AM

Similar story to the parent patch, could you put a file-comment into the test explaining it's a round-trip test?

alok updated this revision to Diff 282625.Aug 3 2020, 7:58 AM
alok retitled this revision from [Debuginfo] (2/N) Support for DW_OP_implicit_pointer for named and unnamed variables (second strategy). to [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_explicit_pointer..
alok added a reviewer: jmorse.

Incorporated comments from @jmorse .

alok added a comment.Aug 3 2020, 7:59 AM

Similar story to the parent patch, could you put a file-comment into the test explaining it's a round-trip test?

Thanks for your comment. Just incorporated your comments.

alok retitled this revision from [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_explicit_pointer. to [Debuginfo] (2/8) [DW_OP_implicit_pointer/second strategy] Support for DW_OP_LLVM_explicit_pointer..Aug 3 2020, 8:14 AM
alok added a comment.Aug 12 2020, 7:15 AM

@jmorse do you have any more comment on this ?

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

alok added a comment.Oct 12 2020, 2:34 AM

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

Thanks for your comment. I shall update the patch description and IR documentation as well.

alok edited the summary of this revision. (Show Details)Oct 15 2020, 11:38 PM

hmm, possibly more words in the patch description (& IR documentation). of this and the previous patch - what is implicit_pointer V explicit_pointer? Maybe some examples in the patch description and IR documentation about how they could be used?

Thanks for your comment. I shall update the patch description and IR documentation as well.

The patch description is updated.

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

alok added a comment.Oct 21 2020, 12:10 AM

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).
While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.
though I am open to use any other name.

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).

OK, I'm with you so far, that sounds reasonable to me.

While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.

Sorry, I don't think I'm understanding "This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable"

Oh, this is for a case where, say, I wrote code like this:

const int *f1() {
  static const int x = 3;
  return x;
}
void f2() {
  const int *y = f1();
  ...
}

Why does that need a different DW_OP compared to DW_OP_LLVM_implicit_pointer? Presumably we use dbg.values for variables with constant values without needing extra operators? (so a variable with the constant value 3 is call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression()) and a variable that /points to/ the constant value 3 would, I would've thought, be call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression(DW_OP_LLVM_implicit_pointer))

though I am open to use any other name.

alok added a comment.Nov 12 2020, 1:30 AM

Where's the name "explicit" pointer come from? I'm not sure how to read/understand the naming distinction between the names "implicit pointer" and "explicit pointer". Maybe the name should be "LLVM_implicit_pointer" as distinct from the DWARF "implicit_pointer" - that they're roughly the same concept, but the LLVM one is a generalization of it? Or is there something in the implicit/explicit distinction that helps clarify the semantic distinction between the two?

We are using three operators DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_implicit_pointer, DW_OP_implicit_pointer.
Last operator DW_OP_implicit_pointer is dumped to object file and is exact syntax as in DWARF document (DW_OP_implicit_pointer <DIE_reference> <offset_in_DIE>)
Second operator DW_OP_LLVM_implicit_pointer is little variation of DW_OP_implicit_pointer for use till the time the DIE reference is not available with the different syntax (DW_OP_LLVM_implicit_pointer <offset>), where one argument is implicit (first argument of dbg.value intrinsic).

OK, I'm with you so far, that sounds reasonable to me.

While last two operators refer to another variable (Metadata in DW_OP_LLVM_implicit_pointer and DIE reference in DW_OP_implicit_pointer), So this is the variable where we can get the value pointed to by pointer variable (implicit way of getting the value).
The first operator DW_OP_LLVM_explicit_pointer is different than other two operators. This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable, so the name "explicit" is used.

Sorry, I don't think I'm understanding "This operator is to represent the constant value itself than the other variable and it has the direct way of getting the value pointed to by pointer variable"

Oh, this is for a case where, say, I wrote code like this:

const int *f1() {
  static const int x = 3;
  return x;
}
void f2() {
  const int *y = f1();
  ...
}

Why does that need a different DW_OP compared to DW_OP_LLVM_implicit_pointer? Presumably we use dbg.values for variables with constant values without needing extra operators? (so a variable with the constant value 3 is call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression()) and a variable that /points to/ the constant value 3 would, I would've thought, be call void @llvm.dbg.value(metadata i32 3, metadata !11, metadata !DIExpression(DW_OP_LLVM_implicit_pointer))

though I am open to use any other name.

Thanks for this. It makes sense. I shall keep the same name for initial two usage. For this I shall abort the current patch (D84114) and make the necessary changes in first one D84113 .

alok abandoned this revision.Nov 27 2020, 2:33 AM