forked from itanium-cxx-abi/cxx-abi
-
Notifications
You must be signed in to change notification settings - Fork 0
/
prop-F3-interface.html
1056 lines (885 loc) · 25 KB
/
prop-F3-interface.html
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
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<title>SGI Proposal for F-3: Interface Section</title>
<link rel=stylesheet href=small-table.css type="text/css">
<link rel=stylesheet href=code.css type="text/css">
<hr>
<font size=6><i><b>
<p>
SGI Proposal for F-3: Interface Section
</b></i></font size>
<font size=-1>
<p>
<i>Last updated 2 May 2000</i>
</center>
</HEAD>
<BODY>
<p>
<hr>
<p>
<H3> <A NAME="Intro"></A>Introduction</H3>
<p>
The purpose of this proposal is to address Issue F-3, consistency checks,
along with F-4, empty throw specs,
and F-10, function return types.
<p>
The proposal is based on a facility that has been in use on SGI/MIPS
systems for several years,
with the objective of catching mismatches between function calls and
definitions.
In the form implemented,
it is capable of catching result and parameter type mismatches
(not precisely in the case of structured types),
and specifically of catching problems resulting from passing floating
point parameters in floating point registers to varargs functions
expecting them in integer registers (with much less overhead).
<p>
It has been modified below (in purple) to:
<ul>
<li> catch throw specification mismatches,
<li> catch template specialization/instantiation mismatches, and
<li> catch precise structured type mismatches.
</ul>
<p>
It is worth noting that this facility is quite simple in concept,
and its implementation at SGI required little effort.
Nevertheless, the description is a bit involved,
due to two sources of complexity:
<ul>
<li>
We have attempted to minimize the descriptor size,
since there may potentially be a large number of them.
Thus, we have many optional fields present only if required.
<p>
<li>
We support an even smaller descriptor which is sufficient to catch
floating point varargs parameter problems,
since old non-ANSI-compliant code may have them (on MIPS and IA-64),
without full-blown parameter profiles.
</ul>
<p>
<hr>
<p>
<H2> <A NAME="InterfaceSection"></A>Interface Section</H2>
<p>
Interface correctness checking by the linkers
(<b><i>ld</b></i>/<b><i>ld.so</b></i>),
as well as object file transformations,
require information about subprogram interfaces,
especially parameter profiles.
This section is intended to provide this information.
There should be one such section per object file
(including executables and DSOs).
<p>
These descriptors shall be used to describe both actual subprogram
definitions and the parameter profiles of calls.
In the latter case, various information will be missing,
and once the call is verified to match the profile of a callee,
references to its descriptor (e.g. from the events section)
may usually be converted to references to the callee's definition descriptor,
and the call descriptor may be removed.
<p>
The information to be provided has variable length.
Thus, the section's
contents are organized as a sequence of variable-length descriptors,
each with a fixed-length header possibly followed by variable-length data.
The descriptors must be sorted by the symbol table index in field symbol.
Each descriptor must be a multiple of 8 bytes in size,
with null padding between descriptors as required.
<p>
Its section attributes are:
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<TR class=tiny>
<TD><b> name </b></TD>
<TD> <code> .IA_64.interfaces</code> </TD>
</TR>
<TR class=tiny>
<TD><code> sh_type </code></TD>
<TD><code> SHT_IA_64_IFACE </code> </TD>
</TR>
<TR class=tiny>
<TD><code> sh_link </code></TD>
<TD> Section header index of the associated symbol table </TD>
</TR>
<TR class=tiny>
<TD><code> sh_info </code></TD>
<TD> 0 </TD>
</TR>
<TR class=tiny>
<TD><code> sh_flags </code></TD>
<TD><code> SHF_SGI_NOSTRIP </code></TD>
</TR>
<TR class=tiny>
<TD> requirements </TD>
<TD> Must not be stripped </TD>
</TR>
</TABLE>
<p>
The structure of an interface descriptor fixed-length header is given
by the figure below.
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-30: Interface Descriptor Header Format</B>
</CAPTION>
<TR class=small>
<th align=left> <B> Field Name </B> </th>
<th align=center> <B> Type </B> </th>
<th align=left> <B> Comments </B> </th>
</TR>
<TR class=small>
<TD><tt><i> symbol </i></tt></TD>
<TD><tt> ElfXX_Word </tt></TD>
<TD> Symbol table index of subprogram name, or 0 for an indirect call</TD>
</TR>
<TR class=small>
<TD><tt><i> attrs </i></tt></TD>
<TD><tt> ElfXX_Half </tt></TD>
<TD> Attributes: see Figure 4-31 </TD>
</TR>
<TR class=small>
<TD><tt><i> pcnt </i></tt></TD>
<TD><tt> ElfXX_Byte </tt></TD>
<TD> Parameter count <sup>a, b</sup></TD>
</TR>
<TR class=small>
<TD><tt><i> fpmask </i></tt></TD>
<TD><tt> ElfXX_Byte </tt></TD>
<TD> Mask of FP parameter registers <sup>c</sup></TD>
</TR>
</TABLE>
<p>
Notes:
<dl>
<dt> <tt><i> pcnt </i></tt> </dt>
<dd>
<sup>a</sup>
The parameter count and parameter profile below describe the parameter
profile as transformed (not as declared).
They include implicit parameters inserted by the compiler,
including function results converted to implicit result pointers
passed as parameters.
<p>
<sup>b</sup>
The parameter count includes the result if the
<b>SA_FUNCTION</b> attribute is set,
and the first descriptor is for the result.
If the parameter count is 255,
then the parameter list is preceded by a two-byte parameter count.
See Figure 4-32.)
</dd>
<p>
<dt> <tt><i> fpmask </i></tt> </dt>
<dd>
<sup>c</sup>
This mask indicates which of the eight FP parameter registers are used
to pass parameters instead of the corresponding integer registers.
The function result is not considered if <b>SA_FUNCTION</b> is set.
The lowest-order bits of the mask represent the first parameters,
i.e. 0x01 is parameter #1 in f8, 0x02 parameter #2 in f9, etc.
</dd>
</dl>
<p><hr>
<p>
The attributes of a subprogram are encoded in the <i>attrs</i> field as
the following bits.
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-31: Interface Descriptor Subprogram Attributes</B>
</CAPTION>
<TR>
<th align=left> <B> Attribute Name </B> </th>
<th align=center> <B> Value </B> </th>
<th align=left> <B> Comments </B> </th>
</TR>
<TR>
<TD><b> SA_PROTOTYPED </b></TD>
<TD><tt> 0x8000 </tt></TD>
<TD> Does def or ref have prototype?</TD>
</TR>
<TR>
<TD><b> SA_VARARGS </b></TD>
<TD><tt> 0x4000 </tt></TD>
<TD> Is this a varargs subprogram?</TD>
</TR>
<TR>
<TD><b> <font color=purple> SA_INSTANTIATION </font></b></TD>
<TD><tt> 0x2000 </tt></TD>
<TD> Is this a template instantiation?</TD>
</TR>
<TR>
<TD><b> <font color=purple> SA_SPECIALIZATION </font></b></TD>
<TD><tt> 0x1000 </tt></TD>
<TD> Is this a template specialization?</TD>
</TR>
<TR>
<TD><b> SA_FUNCTION </b></TD>
<TD><tt> 0x0400 </tt></TD>
<TD> Does subprogram return a result? </TD>
</TR>
<TR>
<TD><b> SA_NESTED </b></TD>
<TD><tt> 0x0200 </tt></TD>
<TD> Is subprogram nested? </td>
</TR>
<TR>
<TD><b> SA_IGNORE_ERROR </b></TD>
<TD><tt> 0x0100 </tt></TD>
<TD> Don't enforce consistency. </td>
</TR>
<TR>
<TD><b> SA_DEFINITION </b></TD>
<TD><tt> 0x0080 </tt></TD>
<TD> Is this a definition (not just call)?</TD>
</TR>
<TR>
<TD><b> <font color=purple> SA_THROW_SPEC </font></b></TD>
<TD><tt> 0x0040 </tt></TD>
<TD> C++ throw specification follows</TD>
</TR>
<TR>
<TD><b> SA_FREE_REGS </b></TD>
<TD><tt> 0x0020 </tt></TD>
<TD> Free register mask follows. </td>
</TR>
<TR>
<TD><b> SA_PARAMETERS </b></TD>
<TD><tt> 0x0010 </tt></TD>
<TD> Parameter profile follows. </td>
</TR>
</TABLE>
<p>
Notes:
<dl>
<p>
<font color=purple>
<dt> SA_INSTANTIATION </dt>
<dd>
This function was produced as the result of C++ template instantiation.
If it matches another interface descriptor without this flag set,
there is a conflict between an instantiation and a specialization.
</dd>
<p>
<dt> SA_SPECIALIZATION </dt>
<dd>
This function was produced as the result of C++ template specialization,
full or partial.
If it matches another interface descriptor without this flag set,
there is a conflict between an instantiation and a specialization.
</dd>
</font>
<p>
<dt> SA_FUNCTION </dt>
<dd>
This is specified as transformed by the compiler, not necessarily as declared,
e.g. a subprogram treating a structure result by placing it in a buffer
addressed as an implicit first parameter would not be encoded as a function.
</dd>
<p>
<dt> SA_NESTED </dt>
<dd>
Because nested subprograms require a static link in addition to the
usual declared parameters,
if a definition has this attribute all calls should too,
but the opposite condition is not necessary.
</dd>
<p>
<dt> SA_IGNORE_ERROR </dt>
<dd>
Some subprograms may be known to be called inconsistently.
This attribute indicates that any tools checking for inconsistencies
should not reject the objects due to inconsistencies for this subprogram.
</dd>
<font color=purple>
<p>
<dt> SA_THROW_SPEC </dt>
<dd>
The parameter profile is followed by a C++ throw specification.
</dd>
</font>
<p>
<dt> SA_FREE_REGS </dt>
<dd>
A 32-bit free register mask precedes the parameter profile,
specifying integer global registers which are never used in this routine.
A program transformation tool like pixie may use these registers,
subject to the ABI assumptions about caller-saved registers.
The mask must be updated by such a tool if registers are used.
See Figure 4-32.)
</dd>
<p>
<dt> SA_PARAMETERS </dt>
<dd>
Minimal checking may be achieved by including only the fixed-length
part of the interface descriptor,
and omitting the detailed parameter profile.
Doing so changes the meaning of the <i>pcnt</i> field
in the fixed-length header.
See the description of required linker checking below.
</dd>
</dl>
<p><hr>
<p>
The variable-length part of an interface descriptor consists of a list
of parameter descriptors following the fixed-length header,
possibly preceded by a profile size, full parameter count,
free register mask,
<font color=purple>
and/or throw specification offset and count.
</font>
It contains one descriptor for each parameter
(formal for definitions, actual for calls),
plus a leading descriptor for the result of functions.
Ellipsis parameters are not present for varargs subprograms;
the <b>SA_VARARGS</b> attribute indicates this case.
After resolving a reference in a call,
the compiler or linker should replace the caller's actual interface
reference by a reference to the callee's formal interface if they match.
(Observe that a varargs call will never match unless no variable
parameters are passed.
Therefore, the call descriptor should not be removed unless the callee
is defined and non-preemptible,
though it may be merged with others that have the same profile.)
<p>
The structure of the variable-length part of an interface descriptor
is a parameter profile with the form given in the figure below.
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-32: Interface Descriptor Parameter Profile</B>
</CAPTION>
<TR>
<th align=center> <B> Size </B> </th>
<th align=left> <B> Description </B> </th>
</TR>
<TR>
<TD> 2 bytes </TD>
<TD> Size in bytes of profile if any other fields are present </TD>
</TR>
<TR>
<TD> 2 bytes </TD>
<TD> Parameter count if <i>pcnt</i> == 255, else 0 </TD>
</TR>
<TR>
<TD> 4 bytes </TD>
<TD> Free register mask if <b>SA_FREE_REGS</b> is set </TD>
</TR>
<TR>
<TD> 2 bytes </TD>
<TD> <font color=purple>
Offset (from size field) of throw spec if SA_THROW_SPEC is set
</font> </TD>
</TR>
<TR>
<TD> 2 bytes </TD>
<TD> <font color=purple>
Number of throw spec entries if SA_THROW_SPEC is set
</font> </TD>
</TR>
<TR>
<TD> 2+ bytes </TD>
<TD> Result type descriptor if <b>SA_FUNCTION</b> is set </TD>
</TR>
<TR>
<TD> 2+ bytes </TD>
<TD> Parameter #1 type descriptor </TD>
</TR>
<TR>
<TD> 2+ bytes </TD>
<TD> Parameter #2 type descriptor </TD>
</TR>
<TR>
<TD> 2+ bytes </TD>
<TD> ... </TD>
</TR>
<TR>
<TD> 2+ bytes </TD>
<TD> Parameter #<i>pcnt</i> type descriptor </TD>
</TR>
<TR>
<TD> 4 bytes </TD>
<TD> <font color=purple> First throw spec identifier (aligned) </font> </TD>
</TR>
<TR>
<TD> 4 bytes </TD>
<TD> <font color=purple> Second throw spec identifier </font> </TD>
</TR>
<TR>
<TD> </TD>
<TD> ... </TD>
</TR>
<TR>
<TD> 4 bytes </TD>
<TD> <font color=purple> Last throw spec identifier </font> </TD>
</TR>
</TABLE>
<p><hr>
<p>
The structure of each type descriptor is given in the figure below.
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-33: Interface Descriptor Parameter Type Descriptor</B>
</CAPTION>
<TR>
<th align=center> <B> Byte # </B> </th>
<th align=left> <B> Description </B> </th>
</TR>
<TR>
<TD> 1 </TD>
<TD> Flags (high-order nibble) and qualifier count (low-order nibble) </TD>
</TR>
<TR>
<TD> 2 </TD>
<TD> Fundamental type (see Figure 4-35 below) </TD>
</TR>
<TR>
<TD> 3 or 3..6</TD>
<TD> Size if indeterminate for type,
<br>1 or 4 bytes (not aligned) depending on PDM_SIZE flag </TD>
</TR>
<TR>
<TD> j..j+3 (3,4,7) </TD>
<TD> <font color=purple>
RTTI symbol index (4 bytes, not aligned) if PDM_RTTI flag is set
</font> </TD>
</TR>
<TR>
<TD> k (>=3) </TD>
<TD> First qualifier </TD>
</TR>
<TR>
<TD> k+1 </TD>
<TD> Second qualifier </TD>
</TR>
<TR>
<TD> k+2 </TD>
<TD> Additional qualifiers </TD>
</TR>
</TABLE>
<p><hr>
<p>
Each parameter type descriptor begins with two bytes.
It contains several flags and a qualifier count in the first byte
as described in Figure 4-34 below,
and one of the fundamental types from Figure 4-35 below
in the second byte.
Next comes the actual parameter length (in bytes)
for those types with indeterminate length (e.g. FT_struct, FT_union).
If PDM_SIZE is not set, the length is an unsigned byte,
where the maximum value (255) implies at least that length;
if PDM_SIZE is set it is a 32-bit unsigned word (not necessarily aligned),
where the maximum value (0xffffffff) implies at least that length.
<font color=purple>
If PDM_RTTI is set,
the next 4-byte unaligned field is a symbol table index of the RTTI
descriptor for the type.
</font>
If the qualifier count is non-zero,
it will be followed by that number of single-byte type qualifiers
from Figure 4-36 below.
<p>
The masks for the initial byte of each type descriptor are
given in the figure below.
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-34: Interface Descriptor Parameter Type Masks</B>
</CAPTION>
<TR>
<th align=left> <B> Mask Name </B> </th>
<th align=center> <B> Value </B> </th>
<th align=left> <B> Comments </B> </th>
</TR>
<tr><td colspan=3></td></tr>
<TR>
<TD><b> PDM_SIZE </b></TD>
<TD align=center> 0x80 </TD>
<TD> Precise size present? </TD>
</TR>
<TR>
<TD><b> PDM_REFERENCE </b></TD>
<TD align=center> 0x40 </TD>
<TD> Reference parameter? </TD>
</TR>
<TR>
<TD><b> PDM_RTTI </b></TD>
<TD align=center> 0x20 </TD>
<TD> RTTI symbol for type? </TD>
</TR>
<TR>
<TD><b> PDM_QUALIFIERS </b></TD>
<TD align=center> 0x0f </TD>
<TD> Count of type qualifiers >>8 </TD>
</TR>
</TABLE>
<p><hr>
<p>
The possible fundamental types for a type descriptor
(adapted from, but not identical to, DWARF version 1)
are given in the figure below.
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-35: Fundamental Type Names</B>
</CAPTION>
<TR>
<th align=left> <B> Name </B> </th>
<th align=center> <B> Value </B> </th>
<th align=left> <B> Comments </B> </th>
</TR>
<tr><td colspan=3></td></tr>
<TR>
<TD><b> FT_unknown </b></TD>
<TD align=center> 0x00 </TD>
<TD> unknown type </TD>
</TR>
<TR>
<TD><b> FT_signed_char </b></TD>
<TD align=center> 0x01 </TD>
<TD> 8-bit signed character </TD>
</TR>
<TR>
<TD><b> FT_unsigned_char </b></TD>
<TD align=center> 0x02 </TD>
<TD> 8-bit unsigned character </TD>
</TR>
<TR>
<TD><b> FT_signed_short </b></TD>
<TD align=center> 0x03 </TD>
<TD> 16-bit signed short integer </TD>
</TR>
<TR>
<TD><b> FT_unsigned_short </b></TD>
<TD align=center> 0x04 </TD>
<TD> 16-bit unsigned short integer </TD>
</TR>
<TR>
<TD><b> FT_signed_int32 </b></TD>
<TD align=center> 0x05 </TD>
<TD> 32-bit signed integer </TD>
</TR>
<TR>
<TD><b> FT_unsigned_int32 </b></TD>
<TD align=center> 0x06 </TD>
<TD> 32-bit unsigned integer </TD>
</TR>
<TR>
<TD><b> FT_signed_int64 </b></TD>
<TD align=center> 0x07 </TD>
<TD> 64-bit signed integer </TD>
</TR>
<TR>
<TD><b> FT_unsigned_int64 </b></TD>
<TD align=center> 0x08 </TD>
<TD> 64-bit unsigned integer </TD>
</TR>
<TR>
<TD><b> FT_pointer32 </b></TD>
<TD align=center> 0x09 </TD>
<TD> 32-bit pointer </TD>
</TR>
<TR>
<TD><b> FT_pointer64 </b></TD>
<TD align=center> 0x0a </TD>
<TD> 64-bit pointer </TD>
</TR>
<TR>
<TD><b> FT_float32 </b></TD>
<TD align=center> 0x0b </TD>
<TD> 32-bit IEEE floating point </TD>
</TR>
<TR>
<TD><b> FT_float64 </b></TD>
<TD align=center> 0x0c </TD>
<TD> 64-bit IEEE floating point </TD>
</TR>
<TR>
<TD><b> FT_float128 </b></TD>
<TD align=center> 0x0d </TD>
<TD> 128-bit floating point </TD>
</TR>
<TR>
<TD><b> FT_complex64 </b></TD>
<TD align=center> 0x0e </TD>
<TD> 64-bit IEEE complex floating point </TD>
</TR>
<TR>
<TD><b> FT_complex128 </b></TD>
<TD align=center> 0x0f </TD>
<TD> 128-bit IEEE complex floating point </TD>
</TR>
<TR>
<TD><b> FT_complex256 </b></TD>
<TD align=center> 0x10 </TD>
<TD> 256-bit complex floating point </TD>
</TR>
<TR>
<TD><b> FT_void </b></TD>
<TD align=center> 0x11 </TD>
<TD> void type </TD>
</TR>
<TR>
<TD><b> FT_bool32 </b></TD>
<TD align=center> 0x12 </TD>
<TD> 32-bit Boolean (TRUE or FALSE) </TD>
</TR>
<TR>
<TD><b> FT_bool64 </b></TD>
<TD align=center> 0x13 </TD>
<TD> 64-bit Boolean (TRUE or FALSE) </TD>
</TR>
<TR>
<TD><b> FT_label32 </b></TD>
<TD align=center> 0x14 </TD>
<TD> 32-bit label (address) </TD>
</TR>
<TR>
<TD><b> FT_label64 </b></TD>
<TD align=center> 0x15 </TD>
<TD> 64-bit label (address) </TD>
</TR>
<TR>
<TD><b> FT_float80 </b></TD>
<TD align=center> 0x16 </TD>
<TD> 80-bit floating point </TD>
</TR>
<TR>
<TD><b> FT_complex160 </b></TD>
<TD align=center> 0x17 </TD>
<TD> 2x80-bit complex floating point </TD>
</TR>
<tr><td colspan=3></td></tr>
<TR>
<TD><b> FT_struct </b></TD>
<TD align=center> 0x20 </TD>
<TD> structure (record) </TD>
</TR>
<TR>
<TD><b> FT_union </b></TD>
<TD align=center> 0x21 </TD>
<TD> union (variant) </TD>
</TR>
<TR>
<TD><b> FT_enum </b></TD>
<TD align=center> 0x22 </TD>
<TD> enumerated type </TD>
</TR>
<TR>
<TD><b> FT_class </b></TD>
<TD align=center> 0x28 </TD>
<TD> C++ class </TD>
</TR>
</TABLE>
<p><hr>
<p>
The fundamental types in Figure 4-35 may be modified by the qualifiers in
the figure below, also based on [DWARF-1]:
<p>
<TABLE align=center BORDER=2 CELLSPACING=2 CELLPADDING=2>
<hr width=100%>
<CAPTION>
<B>Figure 4-36: Type Qualifiers </B>
</CAPTION>
<TR>
<th align=left> <B> Name </B> </th>
<th align=center> <B> Value </B> </th>
<th align=left> <B> Comments </B> </th>
</TR>
<tr><td colspan=3></td></tr>
<TR>
<TD><b> MOD_pointer_to </b></TD>
<TD align=center> 0x01 </TD>
<TD> Pointer to base type </TD>
</TR>
<TR>
<TD><b> MOD_reference_to </b></TD>
<TD align=center> 0x02 </TD>
<TD> C++ reference to base type </TD>
</TR>
<TR>
<TD><b> MOD_const </b></TD>
<TD align=center> 0x03 </TD>
<TD> const base type </TD>
</TR>
<TR>
<TD><b> MOD_volatile </b></TD>
<TD align=center> 0x04 </TD>
<TD> volatile base type </TD>
</TR>
<TR>
<TD><b> MOD_function </b></TD>
<TD align=center> 0x05 </TD>
<TD> Function returning base type </TD>
</TR>
<TR>
<TD><b> MOD_array_of </b></TD>
<TD align=center> 0x06 </TD>
<TD> Array of base type </TD>
</TR>
</TABLE>
<p><hr>
<p>
<font color=purple>
If SA_THROW_SPEC is set,
the parameter profiles are followed by an array of identifiers
for the types that may be thrown by this routine (in C++).
The offset field gives the offset from the size field of the first
such identifier, at 4-byte alignment (with padding if necessary).
The count field gives the number of identifiers present.
Each identifier is the 4-byte symbol table index of an RTTI structure
for the type.
If the function has an empty throw specification,
offset and count should both be zero.
If SA_THROW_SPEC is not set,
nothing may be assumed about the throw specification;
it may not be checked.
</font>
<p>
<H3><A NAME="OptionalFields"></A>Optional Fields</H3>
<p>
To allow minimal overhead checking of varargs floating point parameters,
as well as full parameter consistency checking,
various parts of the parameter profile, as well as the whole profile,
are optional.
The following rules clarify which parts may be omitted:
<ul>
<p>
<li>
The entire profile is omitted if <b>SA_PARAMETERS</b>,
<b>SA_FREE_REGS</b>, and
<font color=purple> <b>SA_THROW_SPEC</b> </font>
are not set, and <i>pcnt</i> is not 255.
See the linker processing description of minimal checking below
for the treatment in this case.
<p>
<li>
If any profile component is present, the size field must be present.
<p>
<li>
If <i>pcnt</i> is 255, the parameter count field must be present,
equal to the number of parameters, including the result for functions.
(Note that this is the number of parameter register equivalents if
<b>SA_PARAMETERS</b> is not set --
see the linker processing description of minimal checking below.)
If <i>pcnt</i> is smaller, but <b>SA_FREE_REGS</b> is set,
the parameter count field is present (containing zero) for alignment.
<p>
<li>
If <b>SA_FREE_REGS</b> is set, the free register mask must be present
(as well as the parameter count field).
<p>
<li>
<font color=purple>
If <b>SA_THROW_SPEC</b> is set,
the throw specification offset and count must be present,
and the indicated number of type identifiers must follow the parameter
type descriptors.
</font>
<p>
<li>
If <b>SA_PARAMETERS</b> is set,
the number of parameter type descriptors implied by <i>pcnt</i>
or the parameter count field is present.
The first one is the function result type if <b>SA_FUNCTION</b> is set.
These descriptors are described in more detail below.
<p>
<li>
Finally, if the full profile is not a multiple of eight bytes long,
it is padded to a multiple of eight bytes with zeros
(which are not included in the size).
</ul>
<p>
<H3><A NAME="InterfaceLinking"></A>Linker Processing</H3>
<i>
<p>
Full support of the interface descriptor section requires significant
processing by the linker -- its purpose is to provide link-time checking.
This processing involves checking and compression.
This facility has been designed to be used either for minimal checking
with minimal space requirements, or for full checking.
<p>
<h4>Full checking</h4>
<p>
The compiler may generate a descriptor for every subprogram definition
and potentially for every call.
(Only one descriptor is required for multiple calls to the same subprogram,
and if the callee is in the same compilation,
the compiler can check parameters and omit the call descriptors entirely.)
When the linker resolves a call to the callee's definition,
it should check the call descriptor against the definition descriptor.
The rules for compatibility are as follows:
<ol>
<p>
<li>
If this is not a varargs routine (not SA_VARARGS),
then the number of parameters should match.
For each parameter the sizes should match,
and whether it is integer or floating point should match.
<p>
<li>
For a varargs routine (SA_VARARGS),
the fixed parameters should match
(except perhaps for the last one,
which may be a varargs.h va_alist dummy parameter),
and there must be no float ing point parameters in the variable part
unless the call site had a prototype visible (SA_PROTOTYPED).
</ol>