forked from ccoutant/dwarf-locations
-
Notifications
You must be signed in to change notification settings - Fork 0
/
013-generalize-address-spaces.txt
877 lines (698 loc) · 45.6 KB
/
013-generalize-address-spaces.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
Part 10: General Support for Address Spaces
PROBLEM DESCRIPTION
AMDGPU needs to be able to describe addresses that are in different kinds of
memory. Optimized code may need to describe a variable that resides in pieces
that are in different kinds of storage which may include parts of registers,
memory that is in a mixture of memory kinds, implicit values, or be undefined.
DWARF 5 has the concept of segment addresses. However, the segment cannot be
specified within a DWARF expression, which is only able to specify the offset
portion of a segment address. The segment index is only provided by the entity
that specifies the DWARF expression. Therefore, the segment index is a property
that can only be put on complete objects, such as a variable. That makes it only
suitable for describing an entity (such as variable or subprogram code) that is
in a single kind of memory.
AMDGPU uses multiple address spaces. For example, a variable may be allocated in
a register that is partially spilled to the call stack which is in the private
address space, and partially spilled to the local address space. DWARF mentions
address spaces, for example as an argument to the DW_OP_xderef* operations. A
new section that defines address classes is added.
A new attribute DW_AT_address_space is added to pointer and reference types.
This allows the compiler to specify which address space is being used to
represent the pointer or reference type.
DWARF 5 uses the concept of an address in many expression operations but does
not define how it relates to address spaces. For example,
DW_OP_push_object_address pushes the address of an object. Other contexts
implicitly push an address on the stack before evaluating an expression. For
example, the DW_AT_use_location attribute of the DW_TAG_ptr_to_member_type. The
expression belongs to a source language type which may apply to objects
allocated in different kinds of storage. Therefore, it is desirable that the
expression that uses the address can do so without regard to what kind of
storage it specifies, including the address space of a memory location
description. For example, a pointer to member value may want to be applied to an
object that may reside in any address space.
The DWARF 5 DW_OP_xderef* operations allow a value to be converted into an
address of a specified address space which is then read. But it provides no way
to create a memory location description for an address in the non-default
address space. For example, AMDGPU variables can be allocated in the local
address space at a fixed address.
A DW_OP_form_aspace_address operation is added and defined to create a memory
location description from an address and address space. It can be used to
specify the location of a variable that is allocated in a specific address
space. This allows the size of addresses in an address space to be larger than
the generic type. It also allows a consumer great implementation freedom. It
allows the implicit conversion back to a value to be limited only to the default
address space to maintain compatibility with DWARF 5. For other address spaces
the producer can use the new operations that explicitly specify the address
space.
In contrast, if the DW_OP_form_aspace_address operation had been defined to
produce a value, and an implicit conversion to a memory location description was
defined, then it would be limited to the size of the generic type (which matches
the size of the default address space). An implementation would likely have to
use <i>reserved ranges</i> of value to represent different address spaces. Such
a value would likely not match any address value in the actual hardware. That
would require the consumer to have special treatment for such values.
DW_OP_breg* treats the register as containing an address in the default address
space. A DW_OP_aspace_bregx operation is added to allow the address space of the
address held in a register to be specified.
Similarly, DW_OP_implicit_pointer treats its implicit pointer value as being in
the default address space. A DW_OP_aspace_implicit_pointer operation is added to
allow the address space to be specified.
Almost all uses of addresses in DWARF 5 are limited to defining location
descriptions, or to be dereferenced to read memory. The exception is
DW_CFA_val_offset which uses the address to set the value of a register. In
order to support address spaces, the CFA DWARF expression is defined to be a
memory location description. This allows it to specify an address space which is
used to convert the offset address back to an address in that address space.
This approach of extending memory location descriptions to support address
spaces, allows all existing DWARF 5 expressions to have the identical semantics.
It allows the compiler to explicitly specify the address space it is using. For
example, a compiler could choose to access private memory in a swizzled manner
when mapping a source language thread to the lane of a wavefront in a SIMT
manner. Or a compiler could choose to access it in an unswizzled manner if
mapping the same language with the wavefront being the thread.
It also allows the compiler to mix the address space it uses to access private
memory. For example, for SIMT it can still spill entire vector registers in an
unswizzled manner, while using a swizzled private memory for SIMT variable
access.
This approach also allows memory location descriptions for different address
spaces to be combined using the regular DW_OP_*piece operations.
Location descriptions are an abstraction of storage. They give freedom to the
consumer on how to implement them. They allow the address space to encode lane
information so they can be used to read memory with only the memory location
description and no extra information. The same set of operations can operate on
locations independent of their kind of storage. The DW_OP_deref* therefore can
be used on any storage kind, including memory location descriptions of different
address spaces. Therefore, the DW_OP_xderef* operations are unnecessary, except
to become a more compact way to encode a non-default address space address
followed by dereferencing it.
PROPOSAL
In Section 2.2 "Attribute Types", add the following row to Table 2.2 "Attribute
names":
----------------------------------------------------------------------------
Table 2.2: Attribute names
=========================== ====================================
Attribute Usage
=========================== ====================================
DW_AT_address_space Architecture specific address space (see 2.x "Address Spaces")
=========================== ====================================
----------------------------------------------------------------------------
In Section 2.5.1 "DWARF Expression Evaluation Context" of the [Allow location
description on the DWARF evaluation stack] proposal, in the definition of "A
current thread", change the paragraph:
----------------------------------------------------------------------------
[non-normative] For example: the DW_OP_regval_type operation.
----------------------------------------------------------------------------
to:
----------------------------------------------------------------------------
[non-normative] For example, the DW_OP_regval_type operation, or the
DW_OP_form_tls_address and DW_OP_form_aspace_address operations when given
an address space that is target architecture thread specific.
----------------------------------------------------------------------------
In Section 2.5.2 "DWARF Expression Value" of the [Allow location
description on the DWARF evaluation stack] proposal change the note:
----------------------------------------------------------------------------
> [For further discussion...]
> It may be desirable to add an implicit pointer base type encoding.
> It would be used for the type of the value that is produced when
> the DW_OP_deref* operation retrieves the full contents of an
> implicit pointer location storage created by the
> DW_OP_implicit_pointer operation. The literal value would record
> the debugging information entry and byte displacement specified by
> the associated DW_OP_implicit_pointer operation.
----------------------------------------------------------------------------
to:
----------------------------------------------------------------------------
> [For further discussion...]
> It may be desirable to add an implicit pointer base type encoding. It
> would be used for the type of the value that is produced when the
> DW_OP_deref* operation retrieves the full contents of an implicit pointer
> location storage created by the DW_OP_implicit_pointer or
> DW_OP_aspace_implicit_pointer operations. The literal value would record
> the debugging information entry and byte displacement specified by the
> associated DW_OP_implicit_pointer or DW_OP_aspace_implicit_pointer
> operations.
----------------------------------------------------------------------------
In Section 2.5.3 "DWARF Location Description" of the [Allow location
description on the DWARF evaluation stack] proposal change the "composite
location storage" note:
----------------------------------------------------------------------------
> [For further discussion...]
> It may be better to add an implicit pointer location storage kind used by
> the DW_OP_implicit_pointer operation. It would specify the debugger
> information entry and byte offset provided by the operations.
----------------------------------------------------------------------------
to:
----------------------------------------------------------------------------
> [For further discussion...]
> It may be better to add an implicit pointer location storage kind used by
> the DW_OP_implicit_pointer and DW_OP_aspace_implicit_pointer operations.
> It would specify the debugger information entry and byte offset provided
> by the operations.
----------------------------------------------------------------------------
In Section 2.5.4.3.4 "Special Value Operations" of [Allow location description
on the DWARF evaluation stack] proposal, in the definition of DW_OP_deref_type,
replace the paragraphs:
----------------------------------------------------------------------------
See 2.5.x.x Implicit Location Description Operations for special rules
concerning implicit location descriptions created by the
DW_OP_implicit_pointer operation.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
See 2.5.x.x Implicit Location Description Operations for special rules
concerning implicit location descriptions created by the
DW_OP_implicit_pointer and DW_OP_aspace_implicit_pointer operations.
----------------------------------------------------------------------------
In Section 2.5.4.3.4 "Special Value Operations" of [Allow location description
on the DWARF evaluation stack] proposal, in the definition of DW_OP_xderef,
replace the paragraphs:
----------------------------------------------------------------------------
The address size S is defined as the address bit size of the target
architecture specific address space that corresponds to AS.
A is adjusted to S bits by zero extending if necessary, and then
treating the least significant S bits as an unsigned value A’.
It creates a location description L with one memory location
description SL. SL specifies the memory location storage LS that
corresponds to AS with a bit offset equal to A’ scaled by 8 (the
byte size).
If AS is an address space that is specific to context elements, then
LS corresponds to the location storage associated with the current
context.
[non-normative] For example, if AS is for per thread storage then LS
is the location storage for the current thread. Therefore, if L is
accessed by an operation, the location storage selected when the
location description was created is accessed, and not the location
storage associated with the current context of the access operation.
The DWARF expression is ill-formed if AS is not one of the values
defined by the target architecture specific DW_ASPACE_* values.
The operation is equivalent to popping A and AS, pushing L, and then
performing DW_OP_deref. The value V retrieved is left on the stack with the
generic type.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
The operation is equivalent to performing DW_OP_swap;
DW_OP_form_aspace_address; DW_OP_deref. The value V retrieved is left on the
stack with the generic type.
----------------------------------------------------------------------------
In Section 2.5.4.3.4 "Special Value Operations" of [Allow location description
on the DWARF evaluation stack] proposal, in the definition of DW_OP_xderef_size,
replace the paragraphs:
----------------------------------------------------------------------------
It creates a location description L as described for DW_OP_xderef.
The operation is equivalent to popping A and AS, pushing L, and then
performing DW_OP_deref_size S. The zero-extended value V retrieved is left
on the stack with the generic type.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
The operation is equivalent to performing DW_OP_swap;
DW_OP_form_aspace_address; DW_OP_deref_size S. The zero-extended value V
retrieved is left on the stack with the generic type.
----------------------------------------------------------------------------
In Section 2.5.4.3.4 "Special Value Operations" of [Allow location description
on the DWARF evaluation stack] proposal, in the definition of DW_OP_xderef_type,
replace the paragraphs:
----------------------------------------------------------------------------
It creates a location description L as described for DW_OP_xderef.
The operation is equivalent to popping A and AS, pushing L, and then
performing DW_OP_deref_type DR. The value V retrieved is left on the stack
with the type T.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
The operation is equivalent to performing DW_OP_swap;
DW_OP_form_aspace_address; DW_OP_deref_type S DR. The value V retrieved is
left on the stack with the type T.
----------------------------------------------------------------------------
In Section 2.5.4.4.3 "Memory Location Description Operations" of [Allow location
description on the DWARF evaluation stack] proposal, after the paragraph that
starts "A location description that is comprised of one byte address memory
location description SL is defined to be a memory byte address location
description" add the following paragraph:
----------------------------------------------------------------------------
DW_ASPACE_none is defined as the target architecture default address space.
See 2.x Address Spaces.
----------------------------------------------------------------------------
In Section 2.5.4.4.3 "Memory Location Description Operations" of [Allow location
description on the DWARF evaluation stack] proposal, after the paragraph:
----------------------------------------------------------------------------
If a stack entry is required to be a location description, but it is
an implicit pointer value IPV with the target architecture default
address space, then it is implicitly converted to a location
description with one single location description specified by IPV.
See 2.5.4.4.5 Implicit Location Description Operations.
----------------------------------------------------------------------------
Add:
> [For further discussion...]
> Is this rule required for DWARF Version 5 backwards compatibility? If not, it
> can be eliminated, and the producer can use DW_OP_form_aspace_address.
In Section 2.5.4.4.3 "Memory Location Description Operations" of [Allow location
description on the DWARF evaluation stack] proposal, after the definition of
DW_OP_addrx add:
----------------------------------------------------------------------------
3. DW_OP_form_aspace_address
DW_OP_form_aspace_address pops top two stack entries. The first must be
an integral type value that represents a target architecture specific
address space identifier AS. The second must be an integral type value
that represents an address A.
The address size S is defined as the address bit size of the target
architecture specific address space that corresponds to AS.
A is adjusted to S bits by zero extending if necessary, and then
treating the least significant S bits as an unsigned value A'.
It pushes a location description L with one memory location description
SL on the stack. SL specifies the memory location storage LS that
corresponds to AS with a bit offset equal to A' scaled by 8 (the byte
size).
If AS is an address space that is specific to context elements, then LS
corresponds to the location storage associated with the current context.
[non-normative] For example, if AS is for per thread storage then LS is
the location storage for the current thread. Therefore, if L is accessed
by an operation, the location storage selected when the location
description was created is accessed, and not the location storage
associated with the current context of the access operation.
The DWARF expression is ill-formed if AS is not one of the values
defined by the target architecture specific DW_ASPACE_* values.
See Section 2.5.4.4.5 "Implicit Location Description Operations" for
special rules concerning implicit pointer values produced by
dereferencing implicit location descriptions created by the
DW_OP_implicit_pointer and DW_OP_aspace_implicit_pointer operations.
----------------------------------------------------------------------------
In Section 2.5.4.4.3 "Memory Location Description Operations" of [Allow location
description on the DWARF evaluation stack] proposal, after the definition of
DW_OP_bregx add:
----------------------------------------------------------------------------
9. DW_OP_aspace_bregx
DW_OP_aspace_bregx has two operands. The first is an unsigned
LEB128 integer that represents a register number R. The second is a signed
LEB128 integer that represents a byte displacement B. It pops one stack
entry that is required to be an integral type value that represents a target
architecture specific address space identifier AS.
The action is the same as for DW_OP_breg<N>, except that R is used as
the register number, B is used as the byte displacement, and AS is used as
the address space identifier.
The DWARF expression is ill-formed if AS is not one of the values defined by
the target architecture specific DW_ASPACE_* values.
> [For further discussion...]
> Could also consider adding DW_OP_aspace_breg0, DW_OP_aspace_breg1, ...,
> DW_OP_aspace_bref31 which would save encoding size.
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, in the
definition of DW_OP_stack_value replace the paragraph:
----------------------------------------------------------------------------
See DW_OP_implicit_pointer (following) for special rules concerning implicit
pointer values produced by dereferencing implicit location descriptions
created by the DW_OP_implicit_pointer operation.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
See DW_OP_implicit_pointer (following) for special rules concerning implicit
pointer values produced by dereferencing implicit location descriptions
created by the DW_OP_implicit_pointer and DW_OP_aspace_implicit_pointer
operations.
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, in the
definition of DW_OP_implicit_pointer replace the paragraph:
----------------------------------------------------------------------------
If IPV is implicitly converted to a location description (only done if AS is
the target architecture default address space), then the resulting location
description RL is:
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
If IPV is either implicitly converted to a location description (only done
if AS is the target architecture default address space) or used by
DW_OP_form_aspace_address (only done if the address space popped by
DW_OP_form_aspace_address is AS), then the resulting location description RL
is:
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, in the
definition of DW_OP_implicit_pointer replace the paragraph:
----------------------------------------------------------------------------
[non-normative] Note that E is evaluated with the context of the expression
accessing IPV, and not the context of the expression that contained the
DW_OP_implicit_pointer operation that created L.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
[non-normative] Note that E is evaluated with the context of the expression
accessing IPV, and not the context of the expression that contained the
DW_OP_implicit_pointer or DW_OP_aspace_implicit_pointer operation that
created L.
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, in the
definition of DW_OP_implicit_pointer replace the paragraph:
----------------------------------------------------------------------------
[non-normative] The restrictions on how an implicit pointer location
description created by DW_OP_implicit_pointer can be used are to simplify
the DWARF consumer. Similarly, for an implicit pointer value created by
DW_OP_deref* and DW_OP_stack_value.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
[non-normative] The restrictions on how an implicit pointer location
description created by DW_OP_implicit_pointer and
DW_OP_aspace_implicit_pointer can be used are to simplify the DWARF
consumer. Similarly, for an implicit pointer value created by DW_OP_deref*
and DW_OP_stack_value.
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, in the
definition of DW_OP_implicit_pointer replace the paragraph:
----------------------------------------------------------------------------
[non-normative] The restrictions on how an implicit pointer location
description created by DW_OP_implicit_pointer can be used are to simplify
the DWARF consumer. Similarly, for an implicit pointer value created by
DW_OP_deref* and DW_OP_stack_value.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
[non-normative] The restrictions on how an implicit pointer location
description created by DW_OP_implicit_pointer and
DW_OP_aspace_implicit_pointer can be used are to simplify the DWARF
consumer. Similarly, for an implicit pointer value created by DW_OP_deref*
and DW_OP_stack_value.
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, after the
definition of DW_OP_implicit_pointer, add:
----------------------------------------------------------------------------
4. DW_OP_aspace_implicit_pointer
DW_OP_aspace_implicit_pointer has two operands that are the same as for
DW_OP_implicit_pointer.
It pops one stack entry that must be an integral type value that
represents a target architecture specific address space identifier AS.
The location description L that is pushed on the stack is the same as
for DW_OP_implicit_pointer, except that the address space identifier
used is AS.
The DWARF expression is ill-formed if AS is not one of the values
defined by the target architecture specific DW_ASPACE_* values.
----------------------------------------------------------------------------
In Section 2.5.4.4.5 "Implicit Location Description Operations" of [Allow
location description on the DWARF evaluation stack] proposal, change the last
three paragraphs from:
----------------------------------------------------------------------------
[non-normative] Typically a DW_OP_implicit_pointer operation is used in a
DWARF expression E1 of a DW_TAG_variable or DW_TAG_formal_parameter
debugging information entry D1's DW_AT_location attribute. The debugging
information entry referenced by the DW_OP_implicit_pointer operation is
typically itself a DW_TAG_variable or DW_TAG_formal_parameter debugging
information entry D2 whose DW_AT_location attribute gives a second DWARF
expression E2.
[non-normative] D1...
[non-normative] However, D2 may be any debugging information entry that
contains a DW_AT_location or DW_AT_const_value attribute (for example,
DW_TAG_dwarf_procedure). By using E2, a consumer can reconstruct the value
of the object when asked to dereference the pointer described by E1 which
contains the DW_OP_implicit_pointer operation.
----------------------------------------------------------------------------
to:
----------------------------------------------------------------------------
[non-normative] Typically a DW_OP_implicit_pointer or
DW_OP_aspace_implicit_pointer operation is used in a DWARF expression E1 of
a DW_TAG_variable or DW_TAG_formal_parameter debugging information entry
D1's DW_AT_location attribute. The debugging information entry referenced by
the* DW_OP_implicit_pointer or DW_OP_aspace_implicit_pointer operations is
typically itself a DW_TAG_variable or DW_TAG_formal_parameter debugging
information entry D2 whose DW_AT_location attribute gives a second DWARF
expression E2.
[non-normative] D1...
[non-normative] However, D2 may be any debugging information entry that
contains a DW_AT_location or DW_AT_const_value attribute (for example,
DW_TAG_dwarf_procedure). By using E2, a consumer can reconstruct the value
of the object when asked to dereference the pointer described by E1 which
contains the DW_OP_implicit_pointer or DW_OP_aspace_implicit_pointer
operation.
----------------------------------------------------------------------------
Add the following after Section 2.12 "Segmented Addresses":
----------------------------------------------------------------------------
2.x Address Spaces
DWARF address spaces correspond to target architecture specific linear
addressable memory areas. They are used in DWARF expression location
descriptions to describe in which target architecture specific memory area
data resides.
[non-normative] Target architecture specific DWARF address spaces may
correspond to hardware supported facilities such as memory utilizing base
address registers, scratchpad memory, and memory with special interleaving.
The size of addresses in these address spaces may vary. Their access and
allocation may be hardware managed with each thread or group of threads
having access to independent storage. For these reasons they may have
properties that do not allow them to be viewed as part of the unified global
virtual address space accessible by all threads.
[non-normative] It is target architecture specific whether multiple DWARF
address spaces are supported and how source language memory spaces map to
target architecture specific DWARF address spaces. A target architecture may
map multiple source language memory spaces to the same target architecture
specific DWARF address class. Optimization may determine that variable
lifetime and access pattern allows them to be allocated in faster scratchpad
memory represented by a different DWARF address space than the default for
the source language memory space.
Although DWARF address space identifiers are target architecture specific,
DW_ASPACE_none is a common address space supported by all target
architectures, and defined as the target architecture default address space.
DWARF address space identifiers are used by:
* The DW_AT_address_space attribute.
* The DWARF expression operations: DW_OP_aspace_bregx,
DW_OP_form_aspace_address, DW_OP_aspace_implicit_pointer, and
DW_OP_xderef*.
* The CFI instructions: DW_CFA_def_aspace_cfa and DW_CFA_def_aspace_cfa_sf.
----------------------------------------------------------------------------
> [For further discussion...]
> Currently, DWARF defines address class values as being target architecture
> specific, and defines a DW_AT_address_class attribute. With the removal of
> DW_AT_segment in DWARF 6, it is unclear how the address class is intended to
> be used as the term is not used elsewhere. Should these be replaced by this
> proposal's more complete address space? Or are they intended to represent
> source language memory spaces such as in OpenCL?
In Section 3.3.5 "Low-Level Information"
----------------------------------------------------------------------------
> [For further discussion...]
> This rule could be removed and require the producer to create the required
> location description directly using DW_OP_call_frame_cfa or DW_OP_breg*.
> This would also then allow a target to implement the call frames within a
> large register.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
> [For further discussion...]
> This rule could be removed and require the producer to create the required
> location description directly using DW_OP_call_frame_cfa, DW_OP_breg*, or
> DW_OP_aspace_bregx. This would also then allow a target to implement the
> call frames within a large register.
----------------------------------------------------------------------------
In Section 5.3 "Type Modifier Entries", after the paragraph starting "A modified
type entry describing a pointer or reference type...", add the following
paragraph:
----------------------------------------------------------------------------
A modified type entry describing a pointer or reference type (using
DW_TAG_pointer_type, DW_TAG_reference_type or DW_TAG_rvalue_reference_type)
may have a DW_AT_address_space attribute with a constant value AS
representing an architecture specific DWARF address space (see 2.x "Address
Spaces"). If omitted, defaults to DW_ASPACE_none. DR is the offset of a
hypothetical debug information entry D in the current compilation unit for
an integral base type matching the address size of AS. An object P having
the given pointer or reference type are dereferenced as if the
DW_OP_push_object_address; DW_OP_deref_type DR; DW_OP_constu AS;
DW_OP_form_aspace_address operation expression was evaluated with the
current context except: the result kind is location description; the initial
stack is empty; and the object is the location description of P.
----------------------------------------------------------------------------
> [For further discussion...]
> What if the current context does not have a current target architecture
> defined?
> [For further discussion...]
> With the expanded support for DWARF address spaces, it may be worth examining
> if they can be used for what was formerly supported by DWARF 5 segments that
> are being removed in DWARF 6. That would include specifying the address space
> of all code addresses (compilation units, subprograms, subprogram entries,
> labels, subprogram types, etc.). Either the code address attributes could be
> extended to allow a exprloc form (so that DW_OP_form_aspace_address can be
> used) or the DW_AT_address_space attribute be allowed on all DIEs that
> formerly allowed DW_AT_segment.
In Section 6.1.1.1 "Contents of the Name Index", replace the bullet:
----------------------------------------------------------------------------
* DW_TAG_variable debugging information entries with a DW_AT_location
attribute that includes a DW_OP_addr or DW_OP_form_tls_address operator
are included; otherwise, they are excluded.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
* DW_TAG_variable debugging information entries with a DW_AT_location
attribute that includes a DW_OP_addr, DW_OP_form_aspace_address, or
DW_OP_form_tls_address operation are included; otherwise, they are
excluded.
----------------------------------------------------------------------------
In Section 6.4.1 "Structure of Call Frame Information", for the "val_offset(N)"
register rule, replace:
----------------------------------------------------------------------------
The DWARF is ill-formed if the CFA location description is not a memory byte
address location description, or if the register size does not match the
size of an address in the target architecture default address space.
[non-normative] Since the CFA location description is required to be a
memory byte address location description, the value of val_offset(N) will
also be a memory byte address location description since it is offsetting
the CFA location description by N bytes. Furthermore, the value of
val_offset(N) will be a memory byte address in the target architecture
default address space.
----------------------------------------------------------------------------
with:
----------------------------------------------------------------------------
The DWARF is ill-formed if the CFA location description is not a memory byte
address location description, or if the register size does not match the
size of an address in the address space of the current CFA location
description.
[non-normative] Since the CFA location description is required to be a
memory byte address location description, the value of val_offset(N) will
also be a memory byte address location description since it is offsetting
the CFA location description by N bytes. Furthermore, the value of
val_offset(N) will be a memory byte address in the same address space as the
CFA location description.
----------------------------------------------------------------------------
In Section 6.4.2.2 "CFA Definition Instructions", replace the description of the
first five CFI instructions with the following:
----------------------------------------------------------------------------
1. DW_CFA_def_cfa
The DW_CFA_def_cfa instruction takes two unsigned LEB128 operands
representing a register number R and a (non-factored) byte displacement
B. AS is set to the target architecture default address space
identifier. The required action is to define the current CFA rule to be
equivalent to the result of evaluating the DWARF operation expression
DW_OP_constu AS; DW_OP_aspace_bregx R, B as a location description.
2. DW_CFA_def_cfa_sf
The DW_CFA_def_cfa_sf instruction takes two operands: an unsigned LEB128
value representing a register number R and a signed LEB128 factored byte
displacement B. AS is set to the target architecture default address
space identifier. The required action is to define the current CFA rule
to be equivalent to the result of evaluating the DWARF operation
expression DW_OP_constu AS; DW_OP_aspace_bregx R, B *
data_alignment_factor as a location description.
[non-normative] The action is the same as DW_CFA_def_cfa, except that
the second operand is signed and factored.
3. DW_CFA_def_cfa_register
The DW_CFA_def_cfa_register instruction takes a single unsigned LEB128
operand representing a register number R. The required action is to
define the current CFA rule to be equivalent to the result of evaluating
the DWARF operation expression DW_OP_constu AS; DW_OP_aspace_bregx R, B
as a location description. B and AS are the old CFA byte displacement
and address space respectively.
If the subprogram has no current CFA rule, or the rule was defined by a
DW_CFA_def_cfa_expression instruction, then the DWARF is ill-formed.
4. DW_CFA_def_cfa_offset
The DW_CFA_def_cfa_offset instruction takes a single unsigned LEB128
operand representing a (non-factored) byte displacement B. The required
action is to define the current CFA rule to be equivalent to the result
of evaluating the DWARF operation expression DW_OP_constu AS;
DW_OP_aspace_bregx R, B as a location description. R and AS are the old
CFA register number and address space respectively.
If the subprogram has no current CFA rule, or the rule was defined by a
DW_CFA_def_cfa_expression instruction, then the DWARF is ill-formed.
5. DW_CFA_def_cfa_offset_sf
The DW_CFA_def_cfa_offset_sf instruction takes a signed LEB128 operand
representing a factored byte displacement B. The required action is to
define the current CFA rule to be equivalent to the result of evaluating
the DWARF operation expression DW_OP_constu AS; DW_OP_aspace_bregx R, B
* data_alignment_factor as a location description. R and AS are the old
CFA register number and address space respectively.
If the subprogram has no current CFA rule, or the rule was defined by a
DW_CFA_def_cfa_expression instruction, then the DWARF is ill-formed.
[non-normative] The action is the same as DW_CFA_def_cfa_offset, except
that the operand is signed and factored.
----------------------------------------------------------------------------
In Section 6.4.2.2 "CFA Definition Instructions", after DW_CFA_def_cfa_sf add
the following CFI instructions and renumber the following list items:
----------------------------------------------------------------------------
3. DW_CFA_def_aspace_cfa
The DW_CFA_def_aspace_cfa instruction takes three unsigned LEB128
operands representing a register number R, a (non-factored) byte
displacement B, and a target architecture specific address space
identifier AS. The required action is to define the current CFA rule to
be equivalent to the result of evaluating the DWARF operation expression
DW_OP_constu AS; DW_OP_aspace_bregx R, B as a location description.
If AS is not one of the values defined by the target architecture
specific DW_ASPACE_* values then the DWARF expression is ill-formed.
4. DW_CFA_def_aspace_cfa_sf
The DW_CFA_def_aspace_cfa_sf instruction takes three operands: an
unsigned LEB128 value representing a register number R, a signed LEB128
factored byte displacement B, and an unsigned LEB128 value representing
a target architecture specific address space identifier AS. The required
action is to define the current CFA rule to be equivalent to the result
of evaluating the DWARF operation expression DW_OP_constu AS;
DW_OP_aspace_bregx R, B * data_alignment_factor as a location
description.
If AS is not one of the values defined by the target architecture
specific DW_ASPACE_* values, then the DWARF expression is ill-formed.
[non-normative] The action is the same as DW_CFA_aspace_def_cfa, except
that the second operand is signed and factored.
----------------------------------------------------------------------------
In Section 7.4 "32-Bit and 64-Bit DWARF Formats" list item 3's table, add the
following row:
----------------------------------------------------------------------------
================================== ===================================
Form Role
================================== ===================================
DW_OP_aspace_implicit_pointer offset in .debug_info
================================== ===================================
----------------------------------------------------------------------------
In Section 7.5.4 "Attribute Encodings", add the following row to Table 7.5
"Attribute encodings":
----------------------------------------------------------------------------
Table 7.5: Attribute encodings
================================== ====== ==================================
Attribute Name Value Classes
================================== ====== ==================================
DW_AT_address_space TBA constant
================================== ====== ==================================
----------------------------------------------------------------------------
Add the following rows to table 7.9 in Section "7.7.1 Operation Expressions":
----------------------------------------------------------------------------
================================== ===== ======== ==========================
Operation Code Number Notes
of
Operands
================================== ===== ======== ==========================
DW_OP_form_aspace_address TBA 0
DW_OP_aspace_bregx TBA 2 ULEB128 register number,
ULEB128 byte displacement
DW_OP_aspace_implicit_pointer TBA 2 4-byte or 8-byte offset of
DIE, SLEB128 byte
displacement
================================== ===== ======== ==========================
----------------------------------------------------------------------------
After Section 7.13 "Address Class Encodings" add the following section:
----------------------------------------------------------------------------
7.x Address Space Encodings
The value of the common address space encoding DW_ASPACE_none is 0.
----------------------------------------------------------------------------
In Section 7.24 "Call Frame Information", add the following rows to Table 7.29
"Call frame instruction encodings":
----------------------------------------------------------------------------
======================== ====== ===== ================ ================ =====================
Instruction High 2 Low 6 Operand 1 Operand 2 Operand 3
Bits Bits
======================== ====== ===== ================ ================ =====================
DW_CFA_def_aspace_cfa 0 TBA ULEB128 register ULEB128 offset ULEB128 address space
DW_CFA_def_aspace_cfa_sf 0 TBA ULEB128 register SLEB128 offset ULEB128 address space
======================== ====== ===== ================ ================ =====================
----------------------------------------------------------------------------
In Section 7.32 "Type Signature Computation", Table 7.32 "Attributes used in
type signature computation", add the following attribute in alphabetical order
to the list:
----------------------------------------------------------------------------
DW_AT_address_space
----------------------------------------------------------------------------
In Appendix A "Attributes by Tag Value (Informative)", add the following to
Table A.1 Attributes by tag value":
----------------------------------------------------------------------------
Table A.1: Attributes by tag value
============================= =============================
Tag Name Applicable Attributes
============================= =============================
DW_TAG_pointer_type DW_AT_address_space
DW_TAG_reference_type DW_AT_address_space
DW_TAG_rvalue_reference_type DW_AT_address_space
============================= =============================
----------------------------------------------------------------------------