Skip to content

Commit 756ba35

Browse files
committed
[AMDGPU] DWARF proposal review feedback
- Rename DW_OP_LLVM_offset_constu to DW_OP_LLVM_offset_uconst to matches DW_OP_plus_uconst. - Correct DW_OP_LLVM_call_ref to be DW_OP_call_ref. - Move proposed changes to a separate section to clarify that the introduction section is not part of the changes. - Fix formatting typos and add missing reference. - Clarify why DW_OP_LLVM_offset et al do not wrap on overflow. - Correct syntax of augmentation string. Differential Revision: https://reviews.llvm.org/D70523
1 parent dd2c639 commit 756ba35

File tree

1 file changed

+69
-35
lines changed

1 file changed

+69
-35
lines changed

llvm/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.rst

Lines changed: 69 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,20 @@
11
.. _amdgpu-dwarf-6-proposal-for-heterogeneous-debugging:
22

3-
====================================================
3+
****************************************************
44
DWARF Version 6 Proposal For Heterogeneous Debugging
5-
====================================================
5+
****************************************************
66

77
.. contents::
88
:local:
99

1010
.. warning::
1111

12-
This section describes a **provisional proposal** for DWARF Version 6
12+
This document describes a **provisional proposal** for DWARF Version 6
1313
[:ref:`DWARF <amdgpu-dwarf-DWARF>`] to support heterogeneous debugging. It is
1414
not currently fully implemented and is subject to change.
1515

1616
Introduction
17-
------------
17+
============
1818

1919
This document proposes a set of backwards compatible extensions to DWARF Version
2020
5 [:ref:`DWARF <amdgpu-dwarf-DWARF>`] for consideration of inclusion into a
@@ -100,7 +100,7 @@ denote the current lane, much like ``DW_OP_push_object_address`` denotes the
100100
current object. The ``DW_OP_*piece`` operations only allow literal indices.
101101
Therefore, a way to use a computed offset of an arbitrary ___location description
102102
(such as a vector register) is required. See ``DW_OP_LLVM_push_lane``,
103-
``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_constu``, and
103+
``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_uconst``, and
104104
``DW_OP_LLVM_bit_offset``.
105105

106106
If the source language is mapped onto the AMDGPU wavefronts in a SIMT manner
@@ -173,16 +173,26 @@ allowing current DWARF expressions to remain legal. See
173173

174174
The ``DW_OP_plus`` and ``DW_OP_minus`` can be defined to operate on a memory
175175
___location description in the default target architecture specific address space
176-
and a generic type value to produce an updated memory ___location description.
177-
This allows them to continue to be used to offset an address. To generalize
176+
and a generic type value to produce an updated memory ___location description. This
177+
allows them to continue to be used to offset an address. To generalize
178178
offsetting to any ___location description, including ___location descriptions that
179-
describe when bytes are in registers, are implicit, or a composite of these,
180-
the ``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_constu`` and
181-
``DW_OP_LLVM_bit_offset`` operations are added. These do not perform wrapping
182-
which would be hard to define for ___location descriptions of non-memory kinds.
183-
This allows ``DW_OP_push_object_address`` to push a ___location description that
184-
may be in a register, or be an implicit value, and the DWARF expression of
185-
``DW_TAG_ptr_to_member_type`` can contain ``DW_OP_LLVM_offset`` to offset
179+
describe when bytes are in registers, are implicit, or a composite of these, the
180+
``DW_OP_LLVM_offset``, ``DW_OP_LLVM_offset_uconst``, and
181+
``DW_OP_LLVM_bit_offset`` offset operations are added. Unlike ``DW_OP_plus``,
182+
``DW_OP_plus_uconst``, and ``DW_OP_minus`` arithmetic operations, these do not
183+
define that integer overflow causes wrap-around. The offset operations can
184+
operate on ___location storage of any size. For example, implicit ___location storage
185+
could be any number of bits in size. It is simpler to define offsets that exceed
186+
the size of the ___location storage as being ill-formed, than having to force an
187+
implementation to support potentially infinite precision offsets to allow it to
188+
correctly track a series of positive and negative offsets that may transiently
189+
overflow or underflow, but end up in range. This is simple for the arithmetic
190+
operations as they are defined in terms of two's compliment arithmetic on a base
191+
type of a fixed size.
192+
193+
Having the offset operations allows ``DW_OP_push_object_address`` to push a
194+
___location description that may be in a register, or be an implicit value, and the
195+
DWARF expression of ``DW_TAG_ptr_to_member_type`` can contain them to offset
186196
within it. ``DW_OP_LLVM_bit_offset`` generalizes DWARF to work with bit fields
187197
which is not possible in DWARF Version 5.
188198

@@ -340,10 +350,17 @@ implemented as an LLVM vendor extension to DWARF Version 5. If accepted these
340350
names would not include the "\ ``LLVM``\ " and would not use encodings in the
341351
vendor range.
342352

343-
The proposal is organized to follow the section ordering of DWARF Version 5.
344-
It includes notes to indicate the corresponding DWARF Version 5 sections to
345-
which they pertain. Other notes describe additional changes that may be worth
346-
considering, and to raise questions.
353+
The proposal is described in
354+
:ref:`amdgpu-dwarf-proposed-changes-relative-to-dwarf-version-5` and is
355+
organized to follow the section ordering of DWARF Version 5. It includes notes
356+
to indicate the corresponding DWARF Version 5 sections to which they pertain.
357+
Other notes describe additional changes that may be worth considering, and to
358+
raise questions.
359+
360+
.. _amdgpu-dwarf-proposed-changes-relative-to-dwarf-version-5:
361+
362+
Proposed Changes Relative to DWARF Version 5
363+
============================================
347364

348365
General Description
349366
-------------------
@@ -648,7 +665,9 @@ stack assume that the top of the stack (most recently added entry) has index 0.
648665
They allow the stack entries to be either a value or ___location description.
649666

650667
If any stack entry accessed by a stack operation is an incomplete composite
651-
___location description, then the DWARF expression is ill-formed.
668+
___location description (see
669+
:ref:`amdgpu-dwarf-composite-___location-description-operations`), then the DWARF
670+
expression is ill-formed.
652671

653672
.. note::
654673

@@ -753,14 +772,21 @@ expression.
753772
unsigned offset, respectively, of a debugging information entry D in the
754773
current compilation unit.
755774

756-
``DW_OP_LLVM_call_ref`` has one operand that is a 4-byte unsigned value in
757-
the 32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF
758-
format, that represents an offset of a debugging information entry D in a
775+
``DW_OP_call_ref`` has one operand that is a 4-byte unsigned value in the
776+
32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format,
777+
that represents an offset of a debugging information entry D in a
759778
``.debug_info`` section, which may be contained in an executable or shared
760-
object file other than that containing the operation. For references from one
761-
executable or shared object file to another, the relocation must be
779+
object file other than that containing the operation. For references from
780+
one executable or shared object file to another, the relocation must be
762781
performed by the consumer.
763782

783+
.. note:
784+
785+
It is unclear how crossing from one executable or shared object file to
786+
another can work. How would a consumer know which executable or shared
787+
object file is being referenced? In an ELF file the DWARF is in a
788+
non-ALLOC segment so standard dynamic relocations cannot be used.
789+
764790
*Operand interpretation of* ``DW_OP_call2``\ *,* ``DW_OP_call4``\ *, and*
765791
``DW_OP_call_ref`` *is exactly like that for* ``DW_FORM_ref2``\ *,
766792
``DW_FORM_ref4``\ *, and* ``DW_FORM_ref_addr``\ *, respectively.*
@@ -1161,7 +1187,7 @@ There are these special value operations currently defined:
11611187
on the stack with the generic type.
11621188

11631189
*This operation is deprecated as the* ``DW_OP_LLVM_form_aspace_address``
1164-
operation can be used and provides greater expressiveness.*
1190+
*operation can be used and provides greater expressiveness.*
11651191

11661192
6. ``DW_OP_xderef_size`` *Deprecated*
11671193

@@ -1177,7 +1203,7 @@ There are these special value operations currently defined:
11771203
value V retrieved is left on the stack with the generic type.
11781204

11791205
*This operation is deprecated as the* ``DW_OP_LLVM_form_aspace_address``
1180-
operation can be used and provides greater expressiveness.*
1206+
*operation can be used and provides greater expressiveness.*
11811207

11821208
7. ``DW_OP_xderef_type`` *Deprecated*
11831209

@@ -1195,7 +1221,7 @@ There are these special value operations currently defined:
11951221
retrieved is left on the stack with the type D.
11961222

11971223
*This operation is deprecated as the* ``DW_OP_LLVM_form_aspace_address``
1198-
operation can be used and provides greater expressiveness.*
1224+
*operation can be used and provides greater expressiveness.*
11991225

12001226
8. ``DW_OP_entry_value`` *Deprecated*
12011227

@@ -1304,9 +1330,9 @@ General Location Description Operations
13041330
to the size of the ___location storage specified by SL, then the DWARF
13051331
expression is ill-formed.
13061332

1307-
2. ``DW_OP_LLVM_offset_constu`` *New*
1333+
2. ``DW_OP_LLVM_offset_uconst`` *New*
13081334

1309-
``DW_OP_LLVM_offset_constu`` has a single unsigned LEB128 integer operand
1335+
``DW_OP_LLVM_offset_uconst`` has a single unsigned LEB128 integer operand
13101336
that represents a byte displacement B.
13111337

13121338
The operation is equivalent to performing ``DW_OP_constu B;
@@ -1316,6 +1342,12 @@ General Location Description Operations
13161342
displacements in two bytes than can be done with* ``DW_OP_lit*;
13171343
DW_OP_LLVM_offset``\ *.*
13181344

1345+
.. note::
1346+
1347+
Should this be named ``DW_OP_LLVM_offset_uconst`` to match
1348+
``DW_OP_plus_uconst``, or ``DW_OP_LLVM_offset_constu`` to match
1349+
``DW_OP_constu``?
1350+
13191351
3. ``DW_OP_LLVM_bit_offset`` *New*
13201352

13211353
``DW_OP_LLVM_bit_offset`` pops two stack entries. The first must be an
@@ -1582,7 +1614,7 @@ type.
15821614
entry corresponding to the current subprogram as described in
15831615
:ref:`amdgpu-dwarf-debugging-information-entry-attributes`.
15841616

1585-
The ___location description L is updated as if the ``DW_OP_LLVM_offset_constu
1617+
The ___location description L is updated as if the ``DW_OP_LLVM_offset_uconst
15861618
B`` operation was applied. The updated L is pushed on the stack.
15871619

15881620
7. ``DW_OP_breg0``, ``DW_OP_breg1``, ..., ``DW_OP_breg31``
@@ -1818,7 +1850,7 @@ implicit storage value starting at the bit offset.
18181850

18191851
* Otherwise the DWARF expression is ill-formed.
18201852

1821-
The bit offset of RL is updated as if the ``DW_OP_LLVM_offset_constu B``
1853+
The bit offset of RL is updated as if the ``DW_OP_LLVM_offset_uconst B``
18221854
operation was applied.
18231855

18241856
If a ``DW_OP_stack_value`` operation pops a value that is the same as IPV,
@@ -1868,6 +1900,8 @@ reconstruct the value of the object when asked to dereference the pointer
18681900
described by E*\ :sub:`1` *which contains the* ``DW_OP_implicit_pointer`` or
18691901
``DW_OP_LLVM_aspace_implicit_pointer`` *operation.*
18701902

1903+
.. _amdgpu-dwarf-composite-___location-description-operations:
1904+
18711905
Composite Location Description Operations
18721906
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
18731907

@@ -2773,7 +2807,7 @@ Debugging Information Entry Attributes
27732807

27742808
The format for the augmentation string is:
27752809

2776-
| ``[``\ *vendor*\ ``v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ *
2810+
| ``[``\ *vendor*\ ``:v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ *
27772811
27782812
Where *vendor* is the producer, ``vX.Y`` specifies the major X and minor Y
27792813
version number of the extensions used, and *options* is an optional string
@@ -2861,7 +2895,7 @@ A null-terminated UTF-8 vendor specific augmentation string, which provides
28612895
additional information about the contents of this index. If provided, the
28622896
recommended format for augmentation string is:
28632897

2864-
| ``[``\ *vendor*\ ``v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ *
2898+
| ``[``\ *vendor*\ ``:v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ *
28652899
28662900
Where *vendor* is the producer, ``vX.Y`` specifies the major X and minor Y
28672901
version number of the extensions used in the DWARF of the compilation unit, and
@@ -3089,7 +3123,7 @@ Description Entries. There is at least one CIE in every non-empty
30893123

30903124
The recommended format for the augmentation string is:
30913125

3092-
| ``[``\ *vendor*\ ``v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ *
3126+
| ``[``\ *vendor*\ ``:v``\ *X*\ ``.``\ *Y*\ [\ ``:``\ *options*\ ]\ ``]``\ *
30933127
30943128
Where *vendor* is the producer, ``vX.Y`` specifies the major X and minor Y
30953129
version number of the extensions used, and *options* is an optional string
@@ -3583,7 +3617,7 @@ operations.
35833617
DW_OP_LLVM_form_aspace_address 0xe1 0
35843618
DW_OP_LLVM_push_lane 0xe2 0
35853619
DW_OP_LLVM_offset 0xe3 0
3586-
DW_OP_LLVM_offset_constu 0xe4 1 ULEB128 byte displacement
3620+
DW_OP_LLVM_offset_uconst 0xe4 1 ULEB128 byte displacement
35873621
DW_OP_LLVM_bit_offset 0xe5 0
35883622
DW_OP_LLVM_call_frame_entry_reg 0xe6 1 ULEB128 register number
35893623
DW_OP_LLVM_undefined 0xe7 0

0 commit comments

Comments
 (0)