DW_OP_xderef operation family

[ZaricZoran]

All three definitions of the DW_OP_xderef operation family are wrong and seemed to be copied our really early notes when our understanding of those operations was not correct.

I would also avoid mentioning theses operation until later parts of the series where they are either redefined or deprecated as part of the address space related DWARF extensions.

[t-tye]

It looks like these descriptions match what is in the proposal at:

https://llvm.org/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.html#a-2-5-4-3-4-special-value-operations

Since this location description proposal did not include the address space changes I reworded it to take out references to the DW_OP_form_aspace_address. In the full proposal the descriptions are simpler as they can be defined in terms of the address space operations:

https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html#a-2-5-4-3-4-special-value-operations

[ZaricZoran]

I still don't see the point mentioning the he DW_OP_xderef operations here. I dont feel that they really contribute and just increase the size of this part of the proposal.

Also, the mention of location description being created and referenced doesn't make sense to me in the light of how DWARF 5 was worded and where the location descriptions sit in the hierarchy of the spec.

If we are going down that route at this point of the proposal, shouldn't we have the same logic for: DW_OP_bregX, DW_OP_regval_type and DW_OP_fbreg, where those operation are defined as creating a location description (somewhere unknown) and just deference it?

This seems to me like a interpretation of an implementation detail and not something that should be in the spec. In my mind this has a place in the spec only after we allow a location description on the stack.

[ccoutant]

Closed per discussion in meeting. Wording is good.