Commit | Line | Data |
---|---|---|
f8cd3f85 C |
1 | @node internals |
2 | @chapter Internal Architecture of the Compiler | |
3 | ||
4 | This is meant to describe the C++ frontend for gcc in detail. | |
5 | Questions and comments to mrs@cygnus.com. | |
6 | ||
7 | @index delete, two argument | |
8 | For two argument delete, the second argument is always calculated by | |
9 | ``virtual_size ='' in the source. It currently has a problem, in that | |
10 | object size is not calculated by the virtual destructor and passed back | |
11 | for the second parameter to delete. Destructors need to return a value | |
12 | just like constructors. | |
13 | ||
14 | @index visibility checking | |
15 | Visibility checking in general is unimplemented, there are a few cases | |
16 | where it is implemented. grok_enum_decls should be used in more places | |
17 | to do visibility checking, but this is only the tip of a bigger problem. | |
18 | ||
19 | @index volatile | |
20 | volatile is not implemented in general. | |
21 | ||
22 | @index const | |
23 | const is completely implemented except for function overload selection. | |
24 | ||
25 | @index protected base classes | |
26 | Protected base classes are not fully implemented. | |
27 | ||
28 | @item BLOCK_SUPERCONTEXT | |
29 | In the outermost scope of each function, it points to the FUNCTION_DECL | |
30 | node. It aids in better DWARF support of inline functions. | |
31 | ||
32 | @item DECL_CLASS_CONTEXT | |
33 | Identifys the context that the _DECL was found in. | |
34 | ||
35 | Has values of: | |
36 | ||
37 | RECORD_TYPE, or UNION_TYPE. | |
38 | ||
39 | What things can this be used on: | |
40 | ||
41 | TYPE_DECLs, *_DECLs | |
42 | ||
43 | @item DECL_NESTED_TYPENAME | |
44 | Holds the fully qualified type name. Example, Base::Derived. | |
45 | ||
46 | Has values of: | |
47 | ||
48 | IDENTIFIER_NODE | |
49 | ||
50 | What things can this be used on: | |
51 | ||
52 | TYPE_DECLs | |
53 | ||
54 | @item TYPE_NAME | |
55 | Names the type. | |
56 | ||
57 | Has values of: | |
58 | ||
59 | 0 for things that don't have names. | |
60 | should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and ENUM_TYPEs. | |
61 | TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but shouldn't | |
62 | be. | |
63 | TYPE_DECL for typedefs, unsure why. | |
64 | ||
65 | What things can one use this on: | |
66 | ||
67 | TYPE_DECLs | |
68 | RECORD_TYPEs | |
69 | UNION_TYPEs | |
70 | ENUM_TYPEs | |
71 | ||
72 | How is it used: | |
73 | ||
74 | Used by dwarfout.c to fetch the name of structs, unoins and enums | |
75 | to create AT_name fields. | |
76 | ||
77 | History: | |
78 | ||
79 | It currently points to the TYPE_DECL for RECORD_TYPEs, | |
80 | UNION_TYPEs and ENUM_TYPEs, but it should be history soon. | |
81 | ||
82 | @item DECL_NAME | |
83 | ||
84 | Has values of: | |
85 | ||
86 | 0 for things that don't have names. | |
87 | IDENTIFIER_NODE for TYPE_DECLs. | |
88 | ||
89 | @item TYPE_DECL | |
90 | Used to represent typedefs, and used to represent bindings layers. | |
91 | ||
92 | Components: | |
93 | ||
94 | DECL_NAME is the name of the typedef. For example, foo would | |
95 | be found in the DECL_NAME slot when @code{typedef int foo;} is | |
96 | seen. | |
97 | ||
98 | DECL_SOURCE_LINE identifies what source line number in the | |
99 | source file the declaration was found at. A value of 0 | |
100 | indicates that this TYPE_DECL is just an internal binding layer | |
101 | marker, and does not correspond to a user suppiled typedef. | |
102 | ||
103 | DECL_SOURCE_FILE @xref{DECL_SOURCE_FILE}. | |
104 | ||
105 | @item DECL_IGNORED_P | |
106 | A bit that can be set to inform the debug information output routines in | |
107 | the backend that a certain _DECL node should be totally ignored. | |
108 | ||
109 | Used in cases where it is known that the debugging information will be | |
110 | output in another file, or where a sub-type is known not to be needed | |
111 | because the enclosing type is not needed. | |
112 | ||
113 | A compiler constructed virtual destructor in derived classes that do not | |
114 | define an exlicit destructor that was defined exlicit in a base class | |
115 | has this bit set as well. Also used on __FUNCTION__ and | |
116 | __PRETTY_FUNCTION__ to mark they are ``compiler generated.'' c-decl and | |
117 | c-lex.c both want DECL_IGNORED_P set for ``internally generated vars,'' | |
118 | and ``user-invisible variable.'' | |
119 | ||
120 | Functions built by the C++ front-end such as default destructors, | |
121 | virtual desctructors and default constructors want to be marked that | |
122 | they are compiler generated, but unsure why. | |
123 | ||
124 | Currently, it is used in an absolute way in the C++ front-end, as an | |
125 | optimization, to tell the debug information output routines to not | |
126 | generate debugging information that will be output by another separately | |
127 | compiled file. | |
128 | ||
129 | @findex DECL_SOURCE_FILE | |
130 | @item DECL_SOURCE_FILE | |
131 | Identifies what source file a particular declaration was found in. | |
132 | ||
133 | Has values of: | |
134 | ||
135 | "<built-in>" on TYPE_DECLs to mean the typedef is built in. | |
136 | ||
137 | @item DECL_SOURCE_LINE | |
138 | Identifies what source line number in the source file the declaration | |
139 | was found at. | |
140 | ||
141 | Has values of: | |
142 | ||
143 | 0 for an undefined label. | |
144 | ||
145 | 0 for TYPE_DECLs that are internally generated. | |
146 | ||
147 | 0 for FUNCTION_DECLs for functions generated by the compiler. | |
148 | (not yet, but should be.) | |
149 | ||
150 | @item DECL_VIRTUAL_P | |
151 | A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in tree.h is | |
152 | wrong.) Used in VAR_DECLs to indicate that the variable is a vtable. | |
153 | It is also used in FIELD_DECLs for vtable pointers. | |
154 | ||
155 | What things can this be used on: | |
156 | ||
157 | FIELD_DECLs and VAR_DECLs. | |
158 | ||
159 | @item DECL_VINDEX | |
160 | Used for FUNCTION_DECLs in two different ways. Before the structure | |
161 | containing the FUNCTION_DECL is laid out, DECL_VINDEX may point to a | |
162 | FUNCTION_DECL in a base class which is the FUNCTION_DECL which this | |
163 | FUNCTION_DECL will replace as a virtual function. When the class is | |
164 | laid out, this pointer is changed to an INTEGER_CST node which is | |
165 | suitable for use as an index into the virtual function table. | |
166 | ||
167 | DECL_VINDEX may be a TREE_LIST, that would seem to be a list of | |
168 | overridden FUNCTION_DECLs. add_virtual_function has code to deal with | |
169 | this when it uses the variable base_fndecl_list, but it would seem that | |
170 | somehow, it is possible for the TREE_LIST to pursist until method_call, | |
171 | and it should not. | |
172 | ||
173 | @item TREE_USED | |
174 | ||
175 | Has values of: | |
176 | ||
177 | 0 for unused labels. | |
178 | ||
179 | @item TREE_ADDRESSABLE | |
180 | A flag that is set for any type that has a constructor. | |
181 | ||
182 | @item CLASSTYPE_METHOD_VEC | |
183 | The following is true after finish_struct has been called (on the | |
184 | class?) but not before. Before finish_struct is called, things are | |
185 | different to some extent. Contains a TREE_VEC of methods of the class. | |
186 | The TREE_VEC_LENGTH is the number of differently named methods plus one | |
187 | for the 0th entry. The 0th entry is always allocated, and reserved for | |
188 | ctors and dtors. If there are none, TREE_VEC_ELT(N,0) == NULL_TREE. | |
189 | Each entry of the TREE_VEC is a FUNCTION_DECL. For each FUNCTION_DECL, | |
190 | there is a DECL_CHAIN slot. If the FUNCTION_DECL is the last one with a | |
191 | given name, the DECL_CHAIN slot is NULL_TREE. Otherwise it is the next | |
192 | method that has the same name (but a different signature). It would | |
193 | seem that it is not true that because the DECL_CHAIN slot is used in | |
194 | this way, we cannot call pushdecl to put the method in the global scope | |
195 | (cause that would overwrite the TREE_CHAIN slot), because they use | |
196 | different _CHAINs. | |
197 | ||
198 | friends are kept in TREE_LISTs, so that there's no need to use their | |
199 | TREE_CHAIN slot for anything. | |
200 | ||
201 | Has values of: | |
202 | ||
203 | TREE_VEC | |
204 | ||
205 | @item TYPE_METHOD | |
206 | Related to CLASSTYPE_METHOD_VEC. Chained together with TREE_CHAIN. | |
207 | dbxout.c uses this to get at the methods of a class. | |
208 | ||
209 | @item CLASSTYPE_TAGS | |
210 | CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes of a | |
211 | class. TREE_PURPOSE is the name, TREE_VALUE is the type (pushclass scans | |
212 | these and calls pushtag on them.) | |
213 | ||
214 | finish_struct scans these to produce TYPE_DECLs to add to the | |
215 | TYPE_FIELDS of the type. | |
216 | ||
217 | It is expected that name found in the TREE_PURPOSE slot is unique, | |
218 | resolve_scope_to_name is one such place that depends upon this | |
219 | uniqueness. | |
220 | ||
221 | @item TYPE_FIELDS | |
222 | TYPE_FIELDS is a linked list (via TREE_CHAIN) of member types of a | |
223 | class. The list can contain TYPE_DECLs, but there can also be other | |
224 | things in the list apparently. See also CLASSTYPE_TAGS. | |
225 | ||
226 | @item TREE_PRIVATE | |
227 | Set for FIELD_DECLs by finish_struct. But not uniformly set. | |
228 | ||
229 | The following routines do something with PRIVATE visibility: | |
230 | build_method_call, alter_visibility, finish_struct_methods, | |
231 | finish_struct, convert_to_aggr, CWriteLanguageDecl, CWriteLanguageType, | |
232 | CWriteUseObject, compute_visibility, lookup_field, dfs_pushdecl, | |
233 | GNU_xref_member, dbxout_type_fields, dbxout_type_method_1 | |
234 | ||
235 | @item TREE_PROTECTED | |
236 | The following routines do something with PROTECTED visibility: | |
237 | build_method_call, alter_visibility, finish_struct, convert_to_aggr, | |
238 | CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject, | |
239 | compute_visibility, lookup_field, GNU_xref_member, dbxout_type_fields, | |
240 | dbxout_type_method_1 |