![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gxxint.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc / cp|
Return to gxxint.texi CVS log | Up to [GCC 2.x] / gcc / cp |
1.1 root 1: \input texinfo @c -*-texinfo-*-
2: @c %**start of header
3: @setfilename g++int.info
4: @settitle G++ internals
5: @setchapternewpage odd
6: @c %**end of header
7:
8: @node Top, Limitations of g++, (dir), (dir)
9: @chapter Internal Architecture of the Compiler
10:
11: This is meant to describe the C++ front-end for gcc in detail.
12: Questions and comments to mrs@@cygnus.com.
13:
14: @menu
15: * Limitations of g++::
16: * Routines::
17: * Implementation Specifics::
18: * Glossary::
19: * Macros::
20: * Typical Behavior::
21: * Coding Conventions::
22: * Templates::
23: * Access Control::
24: * Error Reporting::
25: * Parser::
26: * Copying Objects::
27: * Exception Handling::
28: * Free Store::
29: * Concept Index::
30: @end menu
31:
32: @node Limitations of g++, Routines, Top, Top
33: @section Limitations of g++
34:
35: @itemize @bullet
36: @item
37: Limitations on input source code: 240 nesting levels with the parser
38: stacksize (YYSTACKSIZE) set to 500 (the default), and requires around
39: 16.4k swap space per nesting level. The parser needs about 2.09 *
40: number of nesting levels worth of stackspace.
41:
42: @cindex pushdecl_class_level
43: @item
44: I suspect there are other uses of pushdecl_class_level that do not call
45: set_identifier_type_value in tandem with the call to
46: pushdecl_class_level. It would seem to be an omission.
47:
48: @cindex access checking
49: @item
50: Access checking is unimplemented for nested types.
51:
52: @cindex @code{volatile}
53: @item
54: @code{volatile} is not implemented in general.
55:
56: @cindex pointers to members
57: @item
58: Pointers to members are only minimally supported, and there are places
59: where the grammar doesn't even properly accept them yet.
60:
61: @cindex multiple inheritance
62: @item
63: @code{this} will be wrong in virtual members functions defined in a
64: virtual base class, when they are overridden in a derived class, when
65: called via a non-left most object.
66:
67: An example would be:
68:
69: @example
70: extern "C" int printf(const char*, ...);
71: struct A @{ virtual void f() @{ @} @};
72: struct B : virtual A @{ int b; B() : b(0) @{@} void f() @{ b++; @} @};
73: struct C : B @{@};
74: struct D : B @{@};
75: struct E : C, D @{@};
76: int main()
77: @{
78: E e;
79: C& c = e; D& d = e;
80: c.f(); d.f();
81: printf ("C::b = %d, D::b = %d\n", e.C::b, e.D::b);
82: return 0;
83: @}
84: @end example
85:
86: This will print out 2, 0, instead of 1,1.
87:
88: @end itemize
89:
90: @node Routines, Implementation Specifics, Limitations of g++, Top
91: @section Routines
92:
93: This section describes some of the routines used in the C++ front-end.
94:
95: @code{build_vtable} and @code{prepare_fresh_vtable} is used only within
96: the @file{cp-class.c} file, and only in @code{finish_struct} and
97: @code{modify_vtable_entries}.
98:
99: @code{build_vtable}, @code{prepare_fresh_vtable}, and
100: @code{finish_struct} are the only routines that set @code{DECL_VPARENT}.
101:
102: @code{finish_struct} can steal the virtual function table from parents,
103: this prohibits related_vslot from working. When finish_struct steals,
104: we know that
105:
106: @example
107: get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
108: @end example
109:
110: @noindent
111: will get the related binfo.
112:
113: @code{layout_basetypes} does something with the VIRTUALS.
114:
115: Supposedly (according to Tiemann) most of the breadth first searching
116: done, like in @code{get_base_distance} and in @code{get_binfo} was not
117: because of any design decision. I have since found out the at least one
118: part of the compiler needs the notion of depth first binfo searching, I
119: am going to try and convert the whole thing, it should just work. The
120: term left-most refers to the depth first left-most node. It uses
121: @code{MAIN_VARIANT == type} as the condition to get left-most, because
122: the things that have @code{BINFO_OFFSET}s of zero are shared and will
123: have themselves as their own @code{MAIN_VARIANT}s. The non-shared right
124: ones, are copies of the left-most one, hence if it is its own
1.1.1.2 ! root 125: @code{MAIN_VARIANT}, we know it IS a left-most one, if it is not, it is
1.1 root 126: a non-left-most one.
127:
128: @code{get_base_distance}'s path and distance matters in its use in:
129:
130: @itemize @bullet
131: @item
132: @code{prepare_fresh_vtable} (the code is probably wrong)
133: @item
134: @code{init_vfields} Depends upon distance probably in a safe way,
135: build_offset_ref might use partial paths to do further lookups,
136: hack_identifier is probably not properly checking access.
137:
138: @item
139: @code{get_first_matching_virtual} probably should check for
140: @code{get_base_distance} returning -2.
141:
142: @item
143: @code{resolve_offset_ref} should be called in a more deterministic
144: manner. Right now, it is called in some random contexts, like for
145: arguments at @code{build_method_call} time, @code{default_conversion}
146: time, @code{convert_arguments} time, @code{build_unary_op} time,
147: @code{build_c_cast} time, @code{build_modify_expr} time,
148: @code{convert_for_assignment} time, and
149: @code{convert_for_initialization} time.
150:
151: But, there are still more contexts it needs to be called in, one was the
152: ever simple:
153:
154: @example
155: if (obj.*pmi != 7)
156: @dots{}
157: @end example
158:
159: Seems that the problems were due to the fact that @code{TREE_TYPE} of
160: the @code{OFFSET_REF} was not a @code{OFFSET_TYPE}, but rather the type
161: of the referent (like @code{INTEGER_TYPE}). This problem was fixed by
162: changing @code{default_conversion} to check @code{TREE_CODE (x)},
163: instead of only checking @code{TREE_CODE (TREE_TYPE (x))} to see if it
164: was @code{OFFSET_TYPE}.
165:
166: @end itemize
167:
168: @node Implementation Specifics, Glossary, Routines, Top
169: @section Implementation Specifics
170:
171: @itemize @bullet
172: @item Explicit Initialization
173:
174: The global list @code{current_member_init_list} contains the list of
175: mem-initializers specified in a constructor declaration. For example:
176:
177: @example
178: foo::foo() : a(1), b(2) @{@}
179: @end example
180:
181: @noindent
182: will initialize @samp{a} with 1 and @samp{b} with 2.
183: @code{expand_member_init} places each initialization (a with 1) on the
184: global list. Then, when the fndecl is being processed,
185: @code{emit_base_init} runs down the list, initializing them. It used to
186: be the case that g++ first ran down @code{current_member_init_list},
187: then ran down the list of members initializing the ones that weren't
188: explicitly initialized. Things were rewritten to perform the
189: initializations in order of declaration in the class. So, for the above
190: example, @samp{a} and @samp{b} will be initialized in the order that
191: they were declared:
192:
193: @example
194: class foo @{ public: int b; int a; foo (); @};
195: @end example
196:
197: @noindent
198: Thus, @samp{b} will be initialized with 2 first, then @samp{a} will be
199: initialized with 1, regardless of how they're listed in the mem-initializer.
200:
201: @item Argument Matching
202:
203: In early 1993, the argument matching scheme in @sc{gnu} C++ changed
204: significantly. The original code was completely replaced with a new
205: method that will, hopefully, be easier to understand and make fixing
206: specific cases much easier.
207:
208: The @samp{-fansi-overloading} option is used to enable the new code; at
209: some point in the future, it will become the default behavior of the
210: compiler.
211:
212: The file @file{cp-call.c} contains all of the new work, in the functions
213: @code{rank_for_overload}, @code{compute_harshness},
214: @code{compute_conversion_costs}, and @code{ideal_candidate}.
215:
216: Instead of using obscure numerical values, the quality of an argument
217: match is now represented by clear, individual codes. The new data
218: structure @code{struct harshness} (it used to be an @code{unsigned}
219: number) contains:
220:
221: @enumerate a
222: @item the @samp{code} field, to signify what was involved in matching two
223: arguments;
224: @item the @samp{distance} field, used in situations where inheritance
225: decides which function should be called (one is ``closer'' than
226: another);
227: @item and the @samp{int_penalty} field, used by some codes as a tie-breaker.
228: @end enumerate
229:
230: The @samp{code} field is a number with a given bit set for each type of
231: code, OR'd together. The new codes are:
232:
233: @itemize @bullet
234: @item @code{EVIL_CODE}
235: The argument was not a permissible match.
236:
237: @item @code{CONST_CODE}
238: Currently, this is only used by @code{compute_conversion_costs}, to
239: distinguish when a non-@code{const} member function is called from a
240: @code{const} member function.
241:
242: @item @code{ELLIPSIS_CODE}
243: A match against an ellipsis @samp{...} is considered worse than all others.
244:
245: @item @code{USER_CODE}
246: Used for a match involving a user-defined conversion.
247:
248: @item @code{STD_CODE}
249: A match involving a standard conversion.
250:
251: @item @code{PROMO_CODE}
252: A match involving an integral promotion. For these, the
253: @code{int_penalty} field is used to handle the ARM's rule (XXX cite)
254: that a smaller @code{unsigned} type should promote to a @code{int}, not
255: to an @code{unsigned int}.
256:
257: @item @code{QUAL_CODE}
258: Used to mark use of qualifiers like @code{const} and @code{volatile}.
259:
260: @item @code{TRIVIAL_CODE}
261: Used for trivial conversions. The @samp{int_penalty} field is used by
262: @code{convert_harshness} to communicate further penalty information back
263: to @code{build_overload_call_real} when deciding which function should
264: be call.
265: @end itemize
266:
267: The functions @code{convert_to_aggr} and @code{build_method_call} use
268: @code{compute_conversion_costs} to rate each argument's suitability for
269: a given candidate function (that's how we get the list of candidates for
270: @code{ideal_candidate}).
271:
272: @end itemize
273:
274: @node Glossary, Macros, Implementation Specifics, Top
275: @section Glossary
276:
277: @table @r
278: @item binfo
279: The main data structure in the compiler used to represent the
280: inheritance relationships between classes. The data in the binfo can be
281: accessed by the BINFO_ accessor macros.
282:
283: @item vtable
284: @itemx virtual function table
285:
286: The virtual function table holds information used in virtual function
287: dispatching. In the compiler, they are usually referred to as vtables,
288: or vtbls. The first index is not used in the normal way, I believe it
289: is probably used for the virtual destructor.
290:
291: @item vfield
292:
293: vfields can be thought of as the base information needed to build
294: vtables. For every vtable that exists for a class, there is a vfield.
295: See also vtable and virtual function table pointer. When a type is used
296: as a base class to another type, the virtual function table for the
297: derived class can be based upon the vtable for the base class, just
298: extended to include the additional virtual methods declared in the
299: derived class. The virtual function table from a virtual base class is
300: never reused in a derived class. @code{is_normal} depends upon this.
301:
302: @item virtual function table pointer
303:
304: These are @code{FIELD_DECL}s that are pointer types that point to
305: vtables. See also vtable and vfield.
306: @end table
307:
308: @node Macros, Typical Behavior, Glossary, Top
309: @section Macros
310:
311: This section describes some of the macros used on trees. The list
312: should be alphabetical. Eventually all macros should be documented
313: here. There are some postscript drawings that can be used to better
1.1.1.2 ! root 314: understand from of the more complex data structures, contact Mike Stump
1.1 root 315: (@code{mrs@@cygnus.com}) for information about them.
316:
317: @table @code
318: @item BINFO_BASETYPES
319: A vector of additional binfos for the types inherited by this basetype.
320: The binfos are fully unshared (except for virtual bases, in which
321: case the binfo structure is shared).
322:
323: If this basetype describes type D as inherited in C,
324: and if the basetypes of D are E anf F,
325: then this vector contains binfos for inheritance of E and F by C.
326:
327: Has values of:
328:
329: TREE_VECs
330:
331:
332: @item BINFO_INHERITANCE_CHAIN
333: Temporarily used to represent specific inheritances. It usually points
334: to the binfo associated with the lesser derived type, but it can be
335: reversed by reverse_path. For example:
336:
337: @example
338: Z ZbY least derived
339: |
340: Y YbX
341: |
342: X Xb most derived
343:
344: TYPE_BINFO (X) == Xb
345: BINFO_INHERITANCE_CHAIN (Xb) == YbX
346: BINFO_INHERITANCE_CHAIN (Yb) == ZbY
347: BINFO_INHERITANCE_CHAIN (Zb) == 0
348: @end example
349:
350: Not sure is the above is really true, get_base_distance has is point
351: towards the most derived type, opposite from above.
352:
353: Set by build_vbase_path, recursive_bounded_basetype_p,
354: get_base_distance, lookup_field, lookup_fnfields, and reverse_path.
355:
356: What things can this be used on:
357:
358: TREE_VECs that are binfos
359:
360:
361: @item BINFO_OFFSET
362: The offset where this basetype appears in its containing type.
363: BINFO_OFFSET slot holds the offset (in bytes) from the base of the
364: complete object to the base of the part of the object that is allocated
365: on behalf of this `type'. This is always 0 except when there is
366: multiple inheritance.
367:
368: Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for example.
369:
370:
371: @item BINFO_VIRTUALS
372: A unique list of functions for the virtual function table. See also
373: TYPE_BINFO_VIRTUALS.
374:
375: What things can this be used on:
376:
377: TREE_VECs that are binfos
378:
379:
380: @item BINFO_VTABLE
381: Used to find the VAR_DECL that is the virtual function table associated
382: with this binfo. See also TYPE_BINFO_VTABLE. To get the virtual
383: function table pointer, see CLASSTYPE_VFIELD.
384:
385: What things can this be used on:
386:
387: TREE_VECs that are binfos
388:
389: Has values of:
390:
391: VAR_DECLs that are virtual function tables
392:
393:
394: @item BLOCK_SUPERCONTEXT
395: In the outermost scope of each function, it points to the FUNCTION_DECL
396: node. It aids in better DWARF support of inline functions.
397:
398:
399: @item CLASSTYPE_TAGS
400: CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a
401: class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans
402: these and calls pushtag on them.)
403:
404: finish_struct scans these to produce TYPE_DECLs to add to the
405: TYPE_FIELDS of the type.
406:
407: It is expected that name found in the TREE_PURPOSE slot is unique,
408: resolve_scope_to_name is one such place that depends upon this
409: uniqueness.
410:
411:
412: @item CLASSTYPE_METHOD_VEC
413: The following is true after finish_struct has been called (on the
414: class?) but not before. Before finish_struct is called, things are
415: different to some extent. Contains a TREE_VEC of methods of the class.
416: The TREE_VEC_LENGTH is the number of differently named methods plus one
417: for the 0th entry. The 0th entry is always allocated, and reserved for
418: ctors and dtors. If there are none, TREE_VEC_ELT(N,0) == NULL_TREE.
419: Each entry of the TREE_VEC is a FUNCTION_DECL. For each FUNCTION_DECL,
420: there is a DECL_CHAIN slot. If the FUNCTION_DECL is the last one with a
421: given name, the DECL_CHAIN slot is NULL_TREE. Otherwise it is the next
422: method that has the same name (but a different signature). It would
423: seem that it is not true that because the DECL_CHAIN slot is used in
424: this way, we cannot call pushdecl to put the method in the global scope
425: (cause that would overwrite the TREE_CHAIN slot), because they use
426: different _CHAINs. finish_struct_methods setups up one version of the
427: TREE_CHAIN slots on the FUNCTION_DECLs.
428:
429: friends are kept in TREE_LISTs, so that there's no need to use their
430: TREE_CHAIN slot for anything.
431:
432: Has values of:
433:
434: TREE_VECs
435:
436:
437: @item CLASSTYPE_VFIELD
438: Seems to be in the process of being renamed TYPE_VFIELD. Use on types
439: to get the main virtual function table pointer. To get the virtual
440: function table use BINFO_VTABLE (TYPE_BINFO ()).
441:
442: Has values of:
443:
444: FIELD_DECLs that are virtual function table pointers
445:
446: What things can this be used on:
447:
448: RECORD_TYPEs
449:
450:
451: @item DECL_CLASS_CONTEXT
452: Identifies the context that the _DECL was found in. For virtual function
453: tables, it points to the type associated with the virtual function
454: table. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_FCONTEXT.
455:
456: The difference between this and DECL_CONTEXT, is that for virtuals
457: functions like:
458:
459: @example
460: struct A
461: @{
462: virtual int f ();
463: @};
464:
465: struct B : A
466: @{
467: int f ();
468: @};
469:
470: DECL_CONTEXT (A::f) == A
471: DECL_CLASS_CONTEXT (A::f) == A
472:
473: DECL_CONTEXT (B::f) == A
474: DECL_CLASS_CONTEXT (B::f) == B
475: @end example
476:
477: Has values of:
478:
479: RECORD_TYPEs, or UNION_TYPEs
480:
481: What things can this be used on:
482:
483: TYPE_DECLs, _DECLs
484:
485:
486: @item DECL_CONTEXT
487: Identifies the context that the _DECL was found in. Can be used on
488: virtual function tables to find the type associated with the virtual
489: function table, but since they are FIELD_DECLs, DECL_FIELD_CONTEXT is a
490: better access method. Internally the same as DECL_FIELD_CONTEXT, so
491: don't us both. See also DECL_FIELD_CONTEXT, DECL_FCONTEXT and
492: DECL_CLASS_CONTEXT.
493:
494: Has values of:
495:
496: RECORD_TYPEs
497:
498:
499: What things can this be used on:
500:
501: @display
502: VAR_DECLs that are virtual function tables
503: _DECLs
504: @end display
505:
506:
507: @item DECL_FIELD_CONTEXT
508: Identifies the context that the FIELD_DECL was found in. Internally the
509: same as DECL_CONTEXT, so don't us both. See also DECL_CONTEXT,
510: DECL_FCONTEXT and DECL_CLASS_CONTEXT.
511:
512: Has values of:
513:
514: RECORD_TYPEs
515:
516: What things can this be used on:
517:
518: @display
519: FIELD_DECLs that are virtual function pointers
520: FIELD_DECLs
521: @end display
522:
523:
524: @item DECL_NESTED_TYPENAME
525: Holds the fully qualified type name. Example, Base::Derived.
526:
527: Has values of:
528:
529: IDENTIFIER_NODEs
530:
531: What things can this be used on:
532:
533: TYPE_DECLs
534:
535:
536: @item DECL_NAME
537:
538: Has values of:
539:
540: @display
541: 0 for things that don't have names
542: IDENTIFIER_NODEs for TYPE_DECLs
543: @end display
544:
545: @item DECL_IGNORED_P
546: A bit that can be set to inform the debug information output routines in
547: the back-end that a certain _DECL node should be totally ignored.
548:
549: Used in cases where it is known that the debugging information will be
550: output in another file, or where a sub-type is known not to be needed
551: because the enclosing type is not needed.
552:
553: A compiler constructed virtual destructor in derived classes that do not
1.1.1.2 ! root 554: define an explicit destructor that was defined explicit in a base class
1.1 root 555: has this bit set as well. Also used on __FUNCTION__ and
556: __PRETTY_FUNCTION__ to mark they are ``compiler generated.'' c-decl and
557: c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,''
558: and ``user-invisible variable.''
559:
560: Functions built by the C++ front-end such as default destructors,
1.1.1.2 ! root 561: virtual destructors and default constructors want to be marked that
1.1 root 562: they are compiler generated, but unsure why.
563:
564: Currently, it is used in an absolute way in the C++ front-end, as an
565: optimization, to tell the debug information output routines to not
566: generate debugging information that will be output by another separately
567: compiled file.
568:
569:
570: @item DECL_VIRTUAL_P
571: A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in tree.h is
572: wrong.) Used in VAR_DECLs to indicate that the variable is a vtable.
573: It is also used in FIELD_DECLs for vtable pointers.
574:
575: What things can this be used on:
576:
577: FIELD_DECLs and VAR_DECLs
578:
579:
580: @item DECL_VPARENT
581: Used to point to the parent type of the vtable if there is one, else it
582: is just the type associated with the vtable. Because of the sharing of
583: virtual function tables that goes on, this slot is not very useful, and
584: is in fact, not used in the compiler at all. It can be removed.
585:
586: What things can this be used on:
587:
588: VAR_DECLs that are virtual function tables
589:
590: Has values of:
591:
592: RECORD_TYPEs maybe UNION_TYPEs
593:
594:
595: @item DECL_FCONTEXT
596: Used to find the first baseclass in which this FIELD_DECL is defined.
597: See also DECL_CONTEXT, DECL_FIELD_CONTEXT and DECL_CLASS_CONTEXT.
598:
599: How it is used:
600:
601: Used when writing out debugging information about vfield and
602: vbase decls.
603:
604: What things can this be used on:
605:
606: FIELD_DECLs that are virtual function pointers
607: FIELD_DECLs
608:
609:
610: @item DECL_REFERENCE_SLOT
611: Used to hold the initialize for the reference.
612:
613: What things can this be used on:
614:
615: PARM_DECLs and VAR_DECLs that have a reference type
616:
617:
618: @item DECL_VINDEX
619: Used for FUNCTION_DECLs in two different ways. Before the structure
620: containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a
621: FUNCTION_DECL in a base class which is the FUNCTION_DECL which this
622: FUNCTION_DECL will replace as a virtual function. When the class is
623: laid out, this pointer is changed to an INTEGER_CST node which is
624: suitable to find an index into the virtual function table. See
625: get_vtable_entry as to how one can find the right index into the virtual
626: function table. The first index 0, of a virtual function table it not
627: used in the normal way, so the first real index is 1.
628:
629: DECL_VINDEX may be a TREE_LIST, that would seem to be a list of
630: overridden FUNCTION_DECLs. add_virtual_function has code to deal with
631: this when it uses the variable base_fndecl_list, but it would seem that
632: somehow, it is possible for the TREE_LIST to pursist until method_call,
633: and it should not.
634:
635:
636: What things can this be used on:
637:
638: FUNCTION_DECLs
639:
640:
641: @item DECL_SOURCE_FILE
642: Identifies what source file a particular declaration was found in.
643:
644: Has values of:
645:
646: "<built-in>" on TYPE_DECLs to mean the typedef is built in
647:
648:
649: @item DECL_SOURCE_LINE
650: Identifies what source line number in the source file the declaration
651: was found at.
652:
653: Has values of:
654:
655: @display
656: 0 for an undefined label
657:
658: 0 for TYPE_DECLs that are internally generated
659:
660: 0 for FUNCTION_DECLs for functions generated by the compiler
661: (not yet, but should be)
662:
663: 0 for ``magic'' arguments to functions, that the user has no
664: control over
665: @end display
666:
667:
668: @item TREE_USED
669:
670: Has values of:
671:
672: 0 for unused labels
673:
674:
675: @item TREE_ADDRESSABLE
676: A flag that is set for any type that has a constructor.
677:
678:
679: @item TREE_COMPLEXITY
680: They seem a kludge way to track recursion, poping, and pushing. They only
681: appear in cp-decl.c and cp-decl2.c, so the are a good candidate for
682: proper fixing, and removal.
683:
684:
685: @item TREE_PRIVATE
686: Set for FIELD_DECLs by finish_struct. But not uniformly set.
687:
688: The following routines do something with PRIVATE access:
689: build_method_call, alter_access, finish_struct_methods,
690: finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType,
691: CWriteUseObject, compute_access, lookup_field, dfs_pushdecl,
692: GNU_xref_member, dbxout_type_fields, dbxout_type_method_1
693:
694:
695: @item TREE_PROTECTED
696: The following routines do something with PROTECTED access:
697: build_method_call, alter_access, finish_struct, convert_to_aggr,
698: CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject,
699: compute_access, lookup_field, GNU_xref_member, dbxout_type_fields,
700: dbxout_type_method_1
701:
702:
703: @item TYPE_BINFO
704: Used to get the binfo for the type.
705:
706: Has values of:
707:
708: TREE_VECs that are binfos
709:
710: What things can this be used on:
711:
712: RECORD_TYPEs
713:
714:
715: @item TYPE_BINFO_BASETYPES
716: See also BINFO_BASETYPES.
717:
718: @item TYPE_BINFO_VIRTUALS
719: A unique list of functions for the virtual function table. See also
720: BINFO_VIRTUALS.
721:
722: What things can this be used on:
723:
724: RECORD_TYPEs
725:
726:
727: @item TYPE_BINFO_VTABLE
728: Points to the virtual function table associated with the given type.
729: See also BINFO_VTABLE.
730:
731: What things can this be used on:
732:
733: RECORD_TYPEs
734:
735: Has values of:
736:
737: VAR_DECLs that are virtual function tables
738:
739:
740: @item TYPE_NAME
741: Names the type.
742:
743: Has values of:
744:
745: @display
746: 0 for things that don't have names.
747: should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and
748: ENUM_TYPEs.
749: TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but
750: shouldn't be.
751: TYPE_DECL for typedefs, unsure why.
752: @end display
753:
754: What things can one use this on:
755:
756: @display
757: TYPE_DECLs
758: RECORD_TYPEs
759: UNION_TYPEs
760: ENUM_TYPEs
761: @end display
762:
763: History:
764:
765: It currently points to the TYPE_DECL for RECORD_TYPEs,
766: UNION_TYPEs and ENUM_TYPEs, but it should be history soon.
767:
768:
769: @item TYPE_METHODS
770: Synonym for @code{CLASSTYPE_METHOD_VEC}. Chained together with
771: @code{TREE_CHAIN}. @file{dbxout.c} uses this to get at the methods of a
772: class.
773:
774:
775: @item TYPE_DECL
776: Used to represent typedefs, and used to represent bindings layers.
777:
778: Components:
779:
780: DECL_NAME is the name of the typedef. For example, foo would
781: be found in the DECL_NAME slot when @code{typedef int foo;} is
782: seen.
783:
784: DECL_SOURCE_LINE identifies what source line number in the
785: source file the declaration was found at. A value of 0
786: indicates that this TYPE_DECL is just an internal binding layer
1.1.1.2 ! root 787: marker, and does not correspond to a user supplied typedef.
1.1 root 788:
789: DECL_SOURCE_FILE
790:
791: @item TYPE_FIELDS
792: A linked list (via @code{TREE_CHAIN}) of member types of a class. The
793: list can contain @code{TYPE_DECL}s, but there can also be other things
794: in the list apparently. See also @code{CLASSTYPE_TAGS}.
795:
796:
797: @item TYPE_VIRTUAL_P
798: A flag used on a @code{FIELD_DECL} or a @code{VAR_DECL}, indicates it is
799: a virtual function table or a pointer to one. When used on a
800: @code{FUNCTION_DECL}, indicates that it is a virtual function. When
801: used on an @code{IDENTIFIER_NODE}, indicates that a function with this
802: same name exists and has been declared virtual.
803:
804: When used on types, it indicates that the type has virtual functions, or
805: is derived from one that does.
806:
807: Not sure if the above about virtual function tables is still true. See
808: also info on @code{DECL_VIRTUAL_P}.
809:
810: What things can this be used on:
811:
812: FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs
813:
814:
815: @item VF_BASETYPE_VALUE
816: Get the associated type from the binfo that caused the given vfield to
817: exist. This is the least derived class (the most parent class) that
818: needed a virtual function table. It is probably the case that all uses
819: of this field are misguided, but they need to be examined on a
820: case-by-case basis. See history for more information on why the
821: previous statement was made.
822:
823: Set at @code{finish_base_struct} time.
824:
825: What things can this be used on:
826:
827: TREE_LISTs that are vfields
828:
829: History:
830:
831: This field was used to determine if a virtual function table's
832: slot should be filled in with a certain virtual function, by
833: checking to see if the type returned by VF_BASETYPE_VALUE was a
834: parent of the context in which the old virtual function existed.
835: This incorrectly assumes that a given type _could_ not appear as
836: a parent twice in a given inheritance lattice. For single
837: inheritance, this would in fact work, because a type could not
838: possibly appear more than once in an inheritance lattice, but
839: with multiple inheritance, a type can appear more than once.
840:
841:
842: @item VF_BINFO_VALUE
843: Identifies the binfo that caused this vfield to exist. If this vfield
844: is from the first direct base class that has a virtual function table,
845: then VF_BINFO_VALUE is NULL_TREE, otherwise it will be the binfo of the
846: direct base where the vfield came from. Can use @code{TREE_VIA_VIRTUAL}
847: on result to find out if it is a virtual base class. Related to the
848: binfo found by
849:
850: @example
851: get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
852: @end example
853:
854: @noindent
855: where @samp{t} is the type that has the given vfield.
856:
857: @example
858: get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
859: @end example
860:
861: @noindent
862: will return the binfo for the the given vfield.
863:
864: May or may not be set at @code{modify_vtable_entries} time. Set at
865: @code{finish_base_struct} time.
866:
867: What things can this be used on:
868:
869: TREE_LISTs that are vfields
870:
871:
872: @item VF_DERIVED_VALUE
873: Identifies the type of the most derived class of the vfield, excluding
874: the the class this vfield is for.
875:
876: Set at @code{finish_base_struct} time.
877:
878: What things can this be used on:
879:
880: TREE_LISTs that are vfields
881:
882:
883: @item VF_NORMAL_VALUE
884: Identifies the type of the most derived class of the vfield, including
885: the class this vfield is for.
886:
887: Set at @code{finish_base_struct} time.
888:
889: What things can this be used on:
890:
891: TREE_LISTs that are vfields
892:
893:
894: @item WRITABLE_VTABLES
895: This is a option that can be defined when building the compiler, that
896: will cause the compiler to output vtables into the data segment so that
897: the vtables maybe written. This is undefined by default, because
898: normally the vtables should be unwritable. People that implement object
899: I/O facilities may, or people that want to change the dynamic type of
900: objects may want to have the vtables writable. Another way of achieving
901: this would be to make a copy of the vtable into writable memory, but the
902: drawback there is that that method only changes the type for one object.
903:
904: @end table
905:
906: @node Typical Behavior, Coding Conventions, Macros, Top
907: @section Typical Behavior
908:
909: @cindex parse errors
910:
911: Whenever seemingly normal code fails with errors like
912: @code{syntax error at `\@{'}, it's highly likely that grokdeclarator is
913: returning a NULL_TREE for whatever reason.
914:
915: @node Coding Conventions, Templates, Typical Behavior, Top
916: @section Coding Conventions
917:
918: It should never be that case that trees are modified in-place by the
919: back-end, @emph{unless} it is guaranteed that the semantics are the same
920: no matter how shared the tree structure is. @file{fold-const.c} still
921: has some cases where this is not true, but rms hypothesizes that this
922: will never be a problem.
923:
924: @node Templates, Access Control, Coding Conventions, Top
925: @section Templates
926:
1.1.1.2 ! root 927: A template is represented by a @code{TEMPLATE_DECL}. The specific
! 928: fields used are:
1.1 root 929:
930: @table @code
1.1.1.2 ! root 931: @item DECL_TEMPLATE_RESULT
! 932: The generic decl on which instantiations are based. This looks just
! 933: like any other decl.
! 934:
! 935: @item DECL_TEMPLATE_PARMS
! 936: The parameters to this template.
1.1 root 937: @end table
938:
1.1.1.2 ! root 939: The generic decl is parsed as much like any other decl as possible,
! 940: given the parameterization. The template decl is not built up until the
! 941: generic decl has been completed. For template classes, a template decl
! 942: is generated for each member function and static data member, as well.
! 943:
! 944: Template members of template classes are represented by a TEMPLATE_DECL
! 945: for the class' parameters around another TEMPLATE_DECL for the member's
! 946: parameters.
! 947:
! 948: All declarations that are instantiations or specializations of templates
! 949: refer to their template and parameters through DECL_TEMPLATE_INFO.
! 950:
! 951: How should I handle parsing member functions with the proper param
! 952: decls? Set them up again or try to use the same ones? Currently we do
! 953: the former. We can probably do this without any extra machinery in
! 954: store_pending_inline, by deducing the parameters from the decl in
! 955: do_pending_inlines. PRE_PARSED_TEMPLATE_DECL?
! 956:
! 957: If a base is a parm, we can't check anything about it. If a base is not
! 958: a parm, we need to check it for name binding. Do finish_base_struct if
! 959: no bases are parameterized (only if none, including indirect, are
! 960: parms). Nah, don't bother trying to do any of this until instantiation
! 961: -- we only need to do name binding in advance.
! 962:
! 963: Always set up method vec and fields, inc. synthesized methods. Really?
! 964: We can't know the types of the copy folks, or whether we need a
! 965: destructor, or can have a default ctor, until we know our bases and
! 966: fields. Otherwise, we can assume and fix ourselves later. Hopefully.
! 967:
1.1 root 968: @node Access Control, Error Reporting, Templates, Top
969: @section Access Control
970: The function compute_access returns one of three values:
971:
972: @table @code
973: @item access_public
974: means that the field can be accessed by the current lexical scope.
975:
976: @item access_protected
977: means that the field cannot be accessed by the current lexical scope
978: because it is protected.
979:
980: @item access_private
981: means that the field cannot be accessed by the current lexical scope
982: because it is private.
983: @end table
984:
985: DECL_ACCESS is used for access declarations; alter_access creates a list
986: of types and accesses for a given decl.
987:
988: Formerly, DECL_@{PUBLIC,PROTECTED,PRIVATE@} corresponded to the return
989: codes of compute_access and were used as a cache for compute_access.
990: Now they are not used at all.
991:
992: TREE_PROTECTED and TREE_PRIVATE are used to record the access levels
993: granted by the containing class. BEWARE: TREE_PUBLIC means something
994: completely unrelated to access control!
995:
996: @node Error Reporting, Parser, Access Control, Top
997: @section Error Reporting
998:
999: The C++ front-end uses a call-back mechanism to allow functions to print
1000: out reasonable strings for types and functions without putting extra
1001: logic in the functions where errors are found. The interface is through
1002: the @code{cp_error} function (or @code{cp_warning}, etc.). The
1003: syntax is exactly like that of @code{error}, except that a few more
1004: conversions are supported:
1005:
1006: @itemize @bullet
1007: @item
1008: %C indicates a value of `enum tree_code'.
1009: @item
1010: %D indicates a *_DECL node.
1011: @item
1012: %E indicates a *_EXPR node.
1013: @item
1014: %L indicates a value of `enum languages'.
1015: @item
1016: %P indicates the name of a parameter (i.e. "this", "1", "2", ...)
1017: @item
1018: %T indicates a *_TYPE node.
1019: @item
1020: %O indicates the name of an operator (MODIFY_EXPR -> "operator =").
1021:
1022: @end itemize
1023:
1024: There is some overlap between these; for instance, any of the node
1025: options can be used for printing an identifier (though only @code{%D}
1026: tries to decipher function names).
1027:
1028: For a more verbose message (@code{class foo} as opposed to just @code{foo},
1029: including the return type for functions), use @code{%#c}.
1030: To have the line number on the error message indicate the line of the
1031: DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want,
1032: use @code{%+D}, or it will default to the first.
1033:
1034: @node Parser, Copying Objects, Error Reporting, Top
1035: @section Parser
1036:
1037: Some comments on the parser:
1038:
1039: The @code{after_type_declarator} / @code{notype_declarator} hack is
1040: necessary in order to allow redeclarations of @code{TYPENAME}s, for
1041: instance
1042:
1043: @example
1044: typedef int foo;
1045: class A @{
1046: char *foo;
1047: @};
1048: @end example
1049:
1050: In the above, the first @code{foo} is parsed as a @code{notype_declarator},
1051: and the second as a @code{after_type_declarator}.
1052:
1053: Ambiguities:
1054:
1055: There are currently four reduce/reduce ambiguities in the parser. They are:
1056:
1057: 1) Between @code{template_parm} and
1058: @code{named_class_head_sans_basetype}, for the tokens @code{aggr
1059: identifier}. This situation occurs in code looking like
1060:
1061: @example
1062: template <class T> class A @{ @};
1063: @end example
1064:
1065: It is ambiguous whether @code{class T} should be parsed as the
1066: declaration of a template type parameter named @code{T} or an unnamed
1067: constant parameter of type @code{class T}. Section 14.6, paragraph 3 of
1068: the January '94 working paper states that the first interpretation is
1069: the correct one. This ambiguity results in two reduce/reduce conflicts.
1070:
1071: 2) Between @code{primary} and @code{type_id} for code like @samp{int()}
1072: in places where both can be accepted, such as the argument to
1073: @code{sizeof}. Section 8.1 of the pre-San Diego working paper specifies
1074: that these ambiguous constructs will be interpreted as @code{typename}s.
1075: This ambiguity results in six reduce/reduce conflicts between
1076: @samp{absdcl} and @samp{functional_cast}.
1077:
1078: 3) Between @code{functional_cast} and
1079: @code{complex_direct_notype_declarator}, for various token strings.
1080: This situation occurs in code looking like
1081:
1082: @example
1083: int (*a);
1084: @end example
1085:
1086: This code is ambiguous; it could be a declaration of the variable
1087: @samp{a} as a pointer to @samp{int}, or it could be a functional cast of
1088: @samp{*a} to @samp{int}. Section 6.8 specifies that the former
1089: interpretation is correct. This ambiguity results in 7 reduce/reduce
1090: conflicts. Another aspect of this ambiguity is code like 'int (x[2]);',
1091: which is resolved at the '[' and accounts for 6 reduce/reduce conflicts
1092: between @samp{direct_notype_declarator} and
1093: @samp{primary}/@samp{overqualified_id}. Finally, there are 4 r/r
1094: conflicts between @samp{expr_or_declarator} and @samp{primary} over code
1095: like 'int (a);', which could probably be resolved but would also
1096: probably be more trouble than it's worth. In all, this situation
1097: accounts for 17 conflicts. Ack!
1098:
1099: The second case above is responsible for the failure to parse 'LinppFile
1100: ppfile (String (argv[1]), &outs, argc, argv);' (from Rogue Wave
1101: Math.h++) as an object declaration, and must be fixed so that it does
1102: not resolve until later.
1103:
1104: 4) Indirectly between @code{after_type_declarator} and @code{parm}, for
1105: type names. This occurs in (as one example) code like
1106:
1107: @example
1108: typedef int foo, bar;
1109: class A @{
1110: foo (bar);
1111: @};
1112: @end example
1113:
1114: What is @code{bar} inside the class definition? We currently interpret
1115: it as a @code{parm}, as does Cfront, but IBM xlC interprets it as an
1116: @code{after_type_declarator}. I believe that xlC is correct, in light
1117: of 7.1p2, which says "The longest sequence of @i{decl-specifiers} that
1118: could possibly be a type name is taken as the @i{decl-specifier-seq} of
1119: a @i{declaration}." However, it seems clear that this rule must be
1120: violated in the case of constructors. This ambiguity accounts for 8
1121: conflicts.
1122:
1123: Unlike the others, this ambiguity is not recognized by the Working Paper.
1124:
1125: @node Copying Objects, Exception Handling, Parser, Top
1126: @section Copying Objects
1127:
1128: The generated copy assignment operator in g++ does not currently do the
1129: right thing for multiple inheritance involving virtual bases; it just
1130: calls the copy assignment operators for its direct bases. What it
1131: should probably do is:
1132:
1133: 1) Split up the copy assignment operator for all classes that have
1134: vbases into "copy my vbases" and "copy everything else" parts. Or do
1135: the trickiness that the constructors do to ensure that vbases don't get
1136: initialized by intermediate bases.
1137:
1138: 2) Wander through the class lattice, find all vbases for which no
1139: intermediate base has a user-defined copy assignment operator, and call
1140: their "copy everything else" routines. If not all of my vbases satisfy
1141: this criterion, warn, because this may be surprising behavior.
1142:
1143: 3) Call the "copy everything else" routine for my direct bases.
1144:
1145: If we only have one direct base, we can just foist everything off onto
1146: them.
1147:
1148: This issue is currently under discussion in the core reflector
1149: (2/28/94).
1150:
1151: @node Exception Handling, Free Store, Copying Objects, Top
1152: @section Exception Handling
1153:
1154: Note, exception handling in g++ is still under development.
1155:
1156: This section describes the mapping of C++ exceptions in the C++
1157: front-end, into the back-end exception handling framework.
1158:
1159: The basic mechanism of exception handling in the back-end is
1160: unwind-protect a la elisp. This is a general, robust, and language
1161: independent representation for exceptions.
1162:
1163: The C++ front-end exceptions are mapping into the unwind-protect
1164: semantics by the C++ front-end. The mapping is describe below.
1165:
1.1.1.2 ! root 1166: When -frtti is used, rtti is used to do exception object type checking,
! 1167: when it isn't used, the encoded name for the type of the object being
! 1168: thrown is used instead. All code that originates exceptions, even code
! 1169: that throws exceptions as a side effect, like dynamic casting, and all
! 1170: code that catches exceptions must be compiled with either -frtti, or
! 1171: -fno-rtti. It is not possible to mix rtti base exception handling
! 1172: objects with code that doesn't use rtti. The exceptions to this, are
! 1173: code that doesn't catch or throw exceptions, catch (...), and code that
! 1174: just rethrows an exception.
! 1175:
! 1176: Currently we use the normal mangling used in building functions names
! 1177: (int's are "i", const char * is PCc) to build the non-rtti base type
! 1178: descriptors for exception handling. These descriptors are just plain
! 1179: NULL terminated strings, and internally they are passed around as char
! 1180: *.
1.1 root 1181:
1182: In C++, all cleanups should be protected by exception regions. The
1183: region starts just after the reason why the cleanup is created has
1184: ended. For example, with an automatic variable, that has a constructor,
1185: it would be right after the constructor is run. The region ends just
1186: before the finalization is expanded. Since the backend may expand the
1187: cleanup multiple times along different paths, once for normal end of the
1188: region, once for non-local gotos, once for returns, etc, the backend
1189: must take special care to protect the finalization expansion, if the
1190: expansion is for any other reason than normal region end, and it is
1191: `inline' (it is inside the exception region). The backend can either
1192: choose to move them out of line, or it can created an exception region
1193: over the finalization to protect it, and in the handler associated with
1194: it, it would not run the finalization as it otherwise would have, but
1195: rather just rethrow to the outer handler, careful to skip the normal
1196: handler for the original region.
1197:
1198: In Ada, they will use the more runtime intensive approach of having
1199: fewer regions, but at the cost of additional work at run time, to keep a
1200: list of things that need cleanups. When a variable has finished
1201: construction, they add the cleanup to the list, when the come to the end
1202: of the lifetime of the variable, the run the list down. If the take a
1203: hit before the section finishes normally, they examine the list for
1204: actions to perform. I hope they add this logic into the back-end, as it
1205: would be nice to get that alternative approach in C++.
1206:
1207: On an rs6000, xlC stores exception objects on that stack, under the try
1208: block. When is unwinds down into a handler, the frame pointer is
1209: adjusted back to the normal value for the frame in which the handler
1210: resides, and the stack pointer is left unchanged from the time at which
1.1.1.2 ! root 1211: the object was thrown. This is so that there is always someplace for
1.1 root 1212: the exception object, and nothing can overwrite it, once we start
1213: throwing. The only bad part, is that the stack remains large.
1214:
1.1.1.2 ! root 1215: The below points out some things that work in g++'s exception handling.
! 1216:
! 1217: All completely constructed temps and local variables are cleaned up in
! 1218: all unwinded scopes. Completely constructed parts of partially
! 1219: constructed objects are cleaned up. This includes partially built
! 1220: arrays. Exception specifications are now handled.
! 1221:
! 1222: The below points out some flaws in g++'s exception handling, as it now
! 1223: stands.
! 1224:
! 1225: Only exact type matching or reference matching of throw types works when
! 1226: -fno-rtti is used. Only works on a SPARC (like Suns), i386, arm and
! 1227: rs6000 machines. Partial support is in for all other machines, but a
! 1228: stack unwinder called __unwind_function has to be written, and added to
! 1229: libgcc2 for them. See below for details on __unwind_function. Don't
! 1230: expect exception handling to work right if you optimize, in fact the
! 1231: compiler will probably core dump. RTL_EXPRs for EH cond variables for
! 1232: && and || exprs should probably be wrapped in UNSAVE_EXPRs, and
! 1233: RTL_EXPRs tweaked so that they can be unsaved, and the UNSAVE_EXPR code
! 1234: should be in the backend, or alternatively, UNSAVE_EXPR should be ripped
! 1235: out and exactly one finalization allowed to be expanded by the backend.
! 1236: I talked with kenner about this, and we have to allow multiple
! 1237: expansions.
! 1238:
! 1239: We only do pointer conversions on exception matching a la 15.3 p2 case
! 1240: 3: `A handler with type T, const T, T&, or const T& is a match for a
! 1241: throw-expression with an object of type E if [3]T is a pointer type and
! 1242: E is a pointer type that can be converted to T by a standard pointer
! 1243: conversion (_conv.ptr_) not involving conversions to pointers to private
! 1244: or protected base classes.' when -frtti is given.
! 1245:
! 1246: We don't call delete on new expressions that die because the ctor threw
! 1247: an exception. See except/18 for a test case.
! 1248:
! 1249: 15.2 para 13: The exception being handled should be rethrown if control
! 1250: reaches the end of a handler of the function-try-block of a constructor
! 1251: or destructor, right now, it is not.
! 1252:
! 1253: 15.2 para 12: If a return statement appears in a handler of
! 1254: function-try-block of a constructor, the program is ill-formed, but this
! 1255: isn't diagnosed.
! 1256:
! 1257: 15.2 para 11: If the handlers of a function-try-block contain a jump
! 1258: into the body of a constructor or destructor, the program is ill-formed,
! 1259: but this isn't diagnosed.
! 1260:
! 1261: 15.2 para 9: Check that the fully constructed base classes and members
! 1262: of an object are destroyed before entering the handler of a
! 1263: function-try-block of a constructor or destructor for that object.
! 1264:
! 1265: build_exception_variant should sort the incoming list, so that it
! 1266: implements set compares, not exact list equality. Type smashing should
! 1267: smash exception specifications using set union.
! 1268:
! 1269: Thrown objects are usually allocated on the heap, in the usual way, but
! 1270: they are never deleted. They should be deleted by the catch clauses.
! 1271: If one runs out of heap space, throwing an object will probably never
! 1272: work. This could be relaxed some by passing an __in_chrg parameter to
! 1273: track who has control over the exception object. Thrown objects are not
! 1274: allocated on the heap when they are pointer to object types.
! 1275:
! 1276: When the backend returns a value, it can create new exception regions
! 1277: that need protecting. The new region should rethrow the object in
! 1278: context of the last associated cleanup that ran to completion.
! 1279:
! 1280: The structure of the code that is generated for C++ exception handling
! 1281: code is shown below:
! 1282:
! 1283: @example
! 1284: Ln: throw value;
! 1285: copy value onto heap
! 1286: jump throw (Ln, id, address of copy of value on heap)
! 1287:
! 1288: try {
! 1289: +Lstart: the start of the main EH region
! 1290: |... ...
! 1291: +Lend: the end of the main EH region
! 1292: } catch (T o) {
! 1293: ...1
! 1294: }
! 1295: Lresume:
! 1296: nop used to make sure there is something before
! 1297: the next region ends, if there is one
! 1298: ... ...
! 1299:
! 1300: jump Ldone
! 1301: [
! 1302: Lmainhandler: handler for the region Lstart-Lend
! 1303: cleanup
! 1304: ] zero or more, depending upon automatic vars with dtors
! 1305: +Lpartial:
! 1306: | jump Lover
! 1307: +Lhere:
! 1308: rethrow (Lhere, same id, same obj);
! 1309: Lterm: handler for the region Lpartial-Lhere
! 1310: call terminate
! 1311: Lover:
! 1312: [
! 1313: [
! 1314: call throw_type_match
! 1315: if (eq) {
! 1316: ] these lines disappear when there is no catch condition
! 1317: +Lsregion2:
! 1318: | ...1
! 1319: | jump Lresume
! 1320: |Lhandler: handler for the region Lsregion2-Leregion2
! 1321: | rethrow (Lresume, same id, same obj);
! 1322: +Leregion2
! 1323: }
! 1324: ] there are zero or more of these sections, depending upon how many
! 1325: catch clauses there are
! 1326: ----------------------------- expand_end_all_catch --------------------------
! 1327: here we have fallen off the end of all catch
! 1328: clauses, so we rethrow to outer
! 1329: rethrow (Lresume, same id, same obj);
! 1330: ----------------------------- expand_end_all_catch --------------------------
! 1331: [
! 1332: L1: maybe throw routine
! 1333: ] depending upon if we have expanded it or not
! 1334: Ldone:
! 1335: ret
! 1336:
! 1337: start_all_catch emits labels: Lresume,
! 1338:
! 1339: #end example
! 1340:
! 1341: The __unwind_function takes a pointer to the throw handler, and is
! 1342: expected to pop the stack frame that was built to call it, as well as
! 1343: the frame underneath and then jump to the throw handler. It must
! 1344: restore all registers to their proper values as well as all other
! 1345: machine state as determined by the context in which we are unwinding
! 1346: into. The way I normally start is to compile:
! 1347:
! 1348: void *g;
! 1349: foo(void* a) { g = a; }
! 1350:
! 1351: with -S, and change the thing that alters the PC (return, or ret
! 1352: usually) to not alter the PC, making sure to leave all other semantics
! 1353: (like adjusting the stack pointer, or frame pointers) in. After that,
! 1354: replicate the prologue once more at the end, again, changing the PC
! 1355: altering instructions, and finally, at the very end, jump to `g'.
! 1356:
! 1357: It takes about a week to write this routine, if someone wants to
! 1358: volunteer to write this routine for any architecture, exception support
! 1359: for that architecture will be added to g++. Please send in those code
! 1360: donations. One other thing that needs to be done, is to double check
! 1361: that __builtin_return_address (0) works.
! 1362:
! 1363: @subsection Specific Targets
! 1364:
! 1365: For the alpha, the __unwind_function will be something resembling:
! 1366:
! 1367: @example
! 1368: void
! 1369: __unwind_function(void *ptr)
! 1370: @{
! 1371: /* First frame */
! 1372: asm ("ldq $15, 8($30)"); /* get the saved frame ptr; 15 is fp, 30 is sp */
! 1373: asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
! 1374:
! 1375: /* Second frame */
! 1376: asm ("ldq $15, 8($30)"); /* fp */
! 1377: asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
! 1378:
! 1379: /* Return */
! 1380: asm ("ret $31, ($16), 1"); /* return to PTR, stored in a0 */
! 1381: @}
! 1382: @end example
! 1383:
! 1384: @noindent
! 1385: However, there are a few problems preventing it from working. First of
! 1386: all, the gcc-internal function @code{__builtin_return_address} needs to
! 1387: work given an argument of 0 for the alpha. As it stands as of August
! 1388: 30th, 1995, the code for @code{BUILT_IN_RETURN_ADDRESS} in @file{expr.c}
! 1389: will definitely not work on the alpha. Instead, we need to define
! 1390: the macros @code{DYNAMIC_CHAIN_ADDRESS} (maybe),
! 1391: @code{RETURN_ADDR_IN_PREVIOUS_FRAME}, and definitely need a new
! 1392: definition for @code{RETURN_ADDR_RTX}.
! 1393:
! 1394: In addition (and more importantly), we need a way to reliably find the
! 1395: frame pointer on the alpha. The use of the value 8 above to restore the
! 1396: frame pointer (register 15) is incorrect. On many systems, the frame
! 1397: pointer is consistently offset to a specific point on the stack. On the
! 1398: alpha, however, the frame pointer is pushed last. First the return
! 1399: address is stored, then any other registers are saved (e.g., @code{s0}),
! 1400: and finally the frame pointer is put in place. So @code{fp} could have
! 1401: an offset of 8, but if the calling function saved any registers at all,
! 1402: they add to the offset.
! 1403:
! 1404: The only places the frame size is noted are with the @samp{.frame}
! 1405: directive, for use by the debugger and the OSF exception handling model
! 1406: (useless to us), and in the initial computation of the new value for
! 1407: @code{sp}, the stack pointer. For example, the function may start with:
! 1408:
! 1409: @example
! 1410: lda $30,-32($30)
! 1411: .frame $15,32,$26,0
! 1412: @end example
! 1413:
! 1414: @noindent
! 1415: The 32 above is exactly the value we need. With this, we can be sure
! 1416: that the frame pointer is stored 8 bytes less---in this case, at 24(sp)).
! 1417: The drawback is that there is no way that I (Brendan) have found to let
! 1418: us discover the size of a previous frame @emph{inside} the definition
! 1419: of @code{__unwind_function}.
! 1420:
! 1421: So to accomplish exception handling support on the alpha, we need two
! 1422: things: first, a way to figure out where the frame pointer was stored,
! 1423: and second, a functional @code{__builtin_return_address} implementation
! 1424: for except.c to be able to use it.
! 1425:
! 1426: @subsection Backend Exception Support
! 1427:
! 1428: The backend must be extended to fully support exceptions. Right now
! 1429: there are a few hooks into the alpha exception handling backend that
! 1430: resides in the C++ frontend from that backend that allows exception
! 1431: handling to work in g++. An exception region is a segment of generated
! 1432: code that has a handler associated with it. The exception regions are
! 1433: denoted in the generated code as address ranges denoted by a starting PC
! 1434: value and an ending PC value of the region. Some of the limitations
! 1435: with this scheme are:
! 1436:
! 1437: @itemize @bullet
! 1438: @item
! 1439: The backend replicates insns for such things as loop unrolling and
! 1440: function inlining. Right now, there are no hooks into the frontend's
! 1441: exception handling backend to handle the replication of insns. When
! 1442: replication happens, a new exception region descriptor needs to be
! 1443: generated for the new region.
! 1444:
! 1445: @item
! 1446: The backend expects to be able to rearrange code, for things like jump
! 1447: optimization. Any rearranging of the code needs have exception region
! 1448: descriptors updated appropriately.
! 1449:
! 1450: @item
! 1451: The backend can eliminate dead code. Any associated exception region
! 1452: descriptor that refers to fully contained code that has been eliminated
! 1453: should also be removed, although not doing this is harmless in terms of
! 1454: semantics.
! 1455:
! 1456: #end itemize
! 1457:
! 1458: The above is not meant to be exhaustive, but does include all things I
! 1459: have thought of so far. I am sure other limitations exist.
! 1460:
! 1461: Below are some notes on the migration of the exception handling code
! 1462: backend from the C++ frontend to the backend.
! 1463:
! 1464: NOTEs are to be used to denote the start of an exception region, and the
! 1465: end of the region. I presume that the interface used to generate these
! 1466: notes in the backend would be two functions, start_exception_region and
! 1467: end_exception_region (or something like that). The frontends are
! 1468: required to call them in pairs. When marking the end of a region, an
! 1469: argument can be passed to indicate the handler for the marked region.
! 1470: This can be passed in many ways, currently a tree is used. Another
! 1471: possibility would be insns for the handler, or a label that denotes a
! 1472: handler. I have a feeling insns might be the the best way to pass it.
! 1473: Semantics are, if an exception is thrown inside the region, control is
! 1474: transfered unconditionally to the handler. If control passes through
! 1475: the handler, then the backend is to rethrow the exception, in the
! 1476: context of the end of the original region. The handler is protected by
! 1477: the conventional mechanisms; it is the frontend's responsibility to
! 1478: protect the handler, if special semantics are required.
! 1479:
! 1480: This is a very low level view, and it would be nice is the backend
! 1481: supported a somewhat higher level view in addition to this view. This
! 1482: higher level could include source line number, name of the source file,
! 1483: name of the language that threw the exception and possibly the name of
! 1484: the exception. Kenner may want to rope you into doing more than just
! 1485: the basics required by C++. You will have to resolve this. He may want
! 1486: you to do support for non-local gotos, first scan for exception handler,
! 1487: if none is found, allow the debugger to be entered, without any cleanups
! 1488: being done. To do this, the backend would have to know the difference
! 1489: between a cleanup-rethrower, and a real handler, if would also have to
! 1490: have a way to know if a handler `matches' a thrown exception, and this
! 1491: is frontend specific.
! 1492:
! 1493: The UNSAVE_EXPR tree code has to be migrated to the backend. Exprs such
! 1494: as TARGET_EXPRs, WITH_CLEANUP_EXPRs, CALL_EXPRs and RTL_EXPRs have to be
! 1495: changed to support unsaving. This is meant to be a complete list.
! 1496: SAVE_EXPRs can be unsaved already. expand_decl_cleanup should be
! 1497: changed to unsave it's argument, if needed. See
! 1498: cp/tree.c:cp_expand_decl_cleanup, unsave_expr_now, unsave_expr, and
! 1499: cp/expr.c:cplus_expand_expr(case UNSAVE_EXPR:) for the UNSAVE_EXPR code.
! 1500: Now, as to why... because kenner already tripped over the exact same
! 1501: problem in Ada, we talked about it, he didn't like any of the solution,
! 1502: but yet, didn't like no solution either. He was willing to live with
! 1503: the drawbacks of this solution. The drawback is unsave_expr_now. It
! 1504: should have a callback into the frontend, to allow the unsaveing of
! 1505: frontend special codes. The callback goes in, inplace of the call to
! 1506: my_friendly_abort.
! 1507:
! 1508: The stack unwinder is one of the hardest parts to do. It is highly
! 1509: machine dependent. The form that kenner seems to like was a couple of
! 1510: macros, that would do the machine dependent grunt work. One preexisting
! 1511: function that might be of some use is __builtin_return_address (). One
! 1512: macro he seemed to want was __builtin_return_address, and the other
! 1513: would do the hard work of fixing up the registers, adjusting the stack
! 1514: pointer, frame pointer, arg pointer and so on.
! 1515:
! 1516: The eh archive (~mrs/eh) might be good reading for understanding the Ada
! 1517: perspective, and some of kenners mindset, and a detailed explanation
! 1518: (Message-Id: <[email protected]>) of the concepts
! 1519: involved.
! 1520:
! 1521: Here is a guide to existing backend type code. It is all in
! 1522: cp/except.c. Check out do_unwind, and expand_builtin_throw for current
! 1523: code on how to figure out what handler matches an exception,
! 1524: emit_exception_table for code on emitting the PC range table that is
! 1525: built during compilation, expand_exception_blocks for code that emits
! 1526: all the handlers at the end of a functions, end_protect to mark the end
! 1527: of an exception region, start_protect to mark the start of an exception
! 1528: region, lang_interim_eh is the master hook used by the backend into the
! 1529: EH backend that now exists in the frontend, and expand_internal_throw to
! 1530: raise an exception.
1.1 root 1531:
1532:
1533: @node Free Store, Concept Index, Exception Handling, Top
1534: @section Free Store
1535:
1536: operator new [] adds a magic cookie to the beginning of arrays for which
1537: the number of elements will be needed by operator delete []. These are
1538: arrays of objects with destructors and arrays of objects that define
1539: operator delete [] with the optional size_t argument. This cookie can
1540: be examined from a program as follows:
1541:
1542: @example
1543: typedef unsigned long size_t;
1544: extern "C" int printf (const char *, ...);
1545:
1546: size_t nelts (void *p)
1547: @{
1548: struct cookie @{
1549: size_t nelts __attribute__ ((aligned (sizeof (double))));
1550: @};
1551:
1552: cookie *cp = (cookie *)p;
1553: --cp;
1554:
1555: return cp->nelts;
1556: @}
1557:
1558: struct A @{
1559: ~A() @{ @}
1560: @};
1561:
1562: main()
1563: @{
1564: A *ap = new A[3];
1565: printf ("%ld\n", nelts (ap));
1566: @}
1567: @end example
1568:
1.1.1.2 ! root 1569: @section Linkage
! 1570: The linkage code in g++ is horribly twisted in order to meet two design goals:
! 1571:
! 1572: 1) Avoid unnecessary emission of inlines and vtables.
! 1573:
! 1574: 2) Support pedantic assemblers like the one in AIX.
! 1575:
! 1576: To meet the first goal, we defer emission of inlines and vtables until
! 1577: the end of the translation unit, where we can decide whether or not they
! 1578: are needed, and how to emit them if they are.
! 1579:
1.1 root 1580: @node Concept Index, , Free Store, Top
1581: @section Concept Index
1582:
1583: @printindex cp
1584:
1585: @bye
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.