|
0
|
1 /* Generate information regarding function declarations and definitions based
|
|
|
2 on information stored in GCC's tree structure. This code implements the
|
|
|
3 -aux-info option.
|
|
|
4 Copyright (C) 1989, 1991, 1994, 1995, 1997, 1998,
|
|
|
5 1999, 2000, 2003, 2004, 2007 Free Software Foundation, Inc.
|
|
|
6 Contributed by Ron Guilmette (rfg@segfault.us.com).
|
|
|
7
|
|
|
8 This file is part of GCC.
|
|
|
9
|
|
|
10 GCC is free software; you can redistribute it and/or modify it under
|
|
|
11 the terms of the GNU General Public License as published by the Free
|
|
|
12 Software Foundation; either version 3, or (at your option) any later
|
|
|
13 version.
|
|
|
14
|
|
|
15 GCC is distributed in the hope that it will be useful, but WITHOUT ANY
|
|
|
16 WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
17 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
18 for more details.
|
|
|
19
|
|
|
20 You should have received a copy of the GNU General Public License
|
|
|
21 along with GCC; see the file COPYING3. If not see
|
|
|
22 <http://www.gnu.org/licenses/>. */
|
|
|
23
|
|
|
24 #include "config.h"
|
|
|
25 #include "system.h"
|
|
|
26 #include "coretypes.h"
|
|
|
27 #include "tm.h"
|
|
|
28 #include "flags.h"
|
|
|
29 #include "tree.h"
|
|
|
30 #include "c-tree.h"
|
|
|
31 #include "toplev.h"
|
|
|
32
|
|
|
33 enum formals_style_enum {
|
|
|
34 ansi,
|
|
|
35 k_and_r_names,
|
|
|
36 k_and_r_decls
|
|
|
37 };
|
|
|
38 typedef enum formals_style_enum formals_style;
|
|
|
39
|
|
|
40
|
|
|
41 static const char *data_type;
|
|
|
42
|
|
|
43 static char *affix_data_type (const char *) ATTRIBUTE_MALLOC;
|
|
|
44 static const char *gen_formal_list_for_type (tree, formals_style);
|
|
|
45 static int deserves_ellipsis (tree);
|
|
|
46 static const char *gen_formal_list_for_func_def (tree, formals_style);
|
|
|
47 static const char *gen_type (const char *, tree, formals_style);
|
|
|
48 static const char *gen_decl (tree, int, formals_style);
|
|
|
49
|
|
|
50 /* Given a string representing an entire type or an entire declaration
|
|
|
51 which only lacks the actual "data-type" specifier (at its left end),
|
|
|
52 affix the data-type specifier to the left end of the given type
|
|
|
53 specification or object declaration.
|
|
|
54
|
|
|
55 Because of C language weirdness, the data-type specifier (which normally
|
|
|
56 goes in at the very left end) may have to be slipped in just to the
|
|
|
57 right of any leading "const" or "volatile" qualifiers (there may be more
|
|
|
58 than one). Actually this may not be strictly necessary because it seems
|
|
|
59 that GCC (at least) accepts `<data-type> const foo;' and treats it the
|
|
|
60 same as `const <data-type> foo;' but people are accustomed to seeing
|
|
|
61 `const char *foo;' and *not* `char const *foo;' so we try to create types
|
|
|
62 that look as expected. */
|
|
|
63
|
|
|
64 static char *
|
|
|
65 affix_data_type (const char *param)
|
|
|
66 {
|
|
|
67 char *const type_or_decl = ASTRDUP (param);
|
|
|
68 char *p = type_or_decl;
|
|
|
69 char *qualifiers_then_data_type;
|
|
|
70 char saved;
|
|
|
71
|
|
|
72 /* Skip as many leading const's or volatile's as there are. */
|
|
|
73
|
|
|
74 for (;;)
|
|
|
75 {
|
|
|
76 if (!strncmp (p, "volatile ", 9))
|
|
|
77 {
|
|
|
78 p += 9;
|
|
|
79 continue;
|
|
|
80 }
|
|
|
81 if (!strncmp (p, "const ", 6))
|
|
|
82 {
|
|
|
83 p += 6;
|
|
|
84 continue;
|
|
|
85 }
|
|
|
86 break;
|
|
|
87 }
|
|
|
88
|
|
|
89 /* p now points to the place where we can insert the data type. We have to
|
|
|
90 add a blank after the data-type of course. */
|
|
|
91
|
|
|
92 if (p == type_or_decl)
|
|
|
93 return concat (data_type, " ", type_or_decl, NULL);
|
|
|
94
|
|
|
95 saved = *p;
|
|
|
96 *p = '\0';
|
|
|
97 qualifiers_then_data_type = concat (type_or_decl, data_type, NULL);
|
|
|
98 *p = saved;
|
|
|
99 return reconcat (qualifiers_then_data_type,
|
|
|
100 qualifiers_then_data_type, " ", p, NULL);
|
|
|
101 }
|
|
|
102
|
|
|
103 /* Given a tree node which represents some "function type", generate the
|
|
|
104 source code version of a formal parameter list (of some given style) for
|
|
|
105 this function type. Return the whole formal parameter list (including
|
|
|
106 a pair of surrounding parens) as a string. Note that if the style
|
|
|
107 we are currently aiming for is non-ansi, then we just return a pair
|
|
|
108 of empty parens here. */
|
|
|
109
|
|
|
110 static const char *
|
|
|
111 gen_formal_list_for_type (tree fntype, formals_style style)
|
|
|
112 {
|
|
|
113 const char *formal_list = "";
|
|
|
114 tree formal_type;
|
|
|
115
|
|
|
116 if (style != ansi)
|
|
|
117 return "()";
|
|
|
118
|
|
|
119 formal_type = TYPE_ARG_TYPES (fntype);
|
|
|
120 while (formal_type && TREE_VALUE (formal_type) != void_type_node)
|
|
|
121 {
|
|
|
122 const char *this_type;
|
|
|
123
|
|
|
124 if (*formal_list)
|
|
|
125 formal_list = concat (formal_list, ", ", NULL);
|
|
|
126
|
|
|
127 this_type = gen_type ("", TREE_VALUE (formal_type), ansi);
|
|
|
128 formal_list
|
|
|
129 = ((strlen (this_type))
|
|
|
130 ? concat (formal_list, affix_data_type (this_type), NULL)
|
|
|
131 : concat (formal_list, data_type, NULL));
|
|
|
132
|
|
|
133 formal_type = TREE_CHAIN (formal_type);
|
|
|
134 }
|
|
|
135
|
|
|
136 /* If we got to here, then we are trying to generate an ANSI style formal
|
|
|
137 parameters list.
|
|
|
138
|
|
|
139 New style prototyped ANSI formal parameter lists should in theory always
|
|
|
140 contain some stuff between the opening and closing parens, even if it is
|
|
|
141 only "void".
|
|
|
142
|
|
|
143 The brutal truth though is that there is lots of old K&R code out there
|
|
|
144 which contains declarations of "pointer-to-function" parameters and
|
|
|
145 these almost never have fully specified formal parameter lists associated
|
|
|
146 with them. That is, the pointer-to-function parameters are declared
|
|
|
147 with just empty parameter lists.
|
|
|
148
|
|
|
149 In cases such as these, protoize should really insert *something* into
|
|
|
150 the vacant parameter lists, but what? It has no basis on which to insert
|
|
|
151 anything in particular.
|
|
|
152
|
|
|
153 Here, we make life easy for protoize by trying to distinguish between
|
|
|
154 K&R empty parameter lists and new-style prototyped parameter lists
|
|
|
155 that actually contain "void". In the latter case we (obviously) want
|
|
|
156 to output the "void" verbatim, and that what we do. In the former case,
|
|
|
157 we do our best to give protoize something nice to insert.
|
|
|
158
|
|
|
159 This "something nice" should be something that is still valid (when
|
|
|
160 re-compiled) but something that can clearly indicate to the user that
|
|
|
161 more typing information (for the parameter list) should be added (by
|
|
|
162 hand) at some convenient moment.
|
|
|
163
|
|
|
164 The string chosen here is a comment with question marks in it. */
|
|
|
165
|
|
|
166 if (!*formal_list)
|
|
|
167 {
|
|
|
168 if (TYPE_ARG_TYPES (fntype))
|
|
|
169 /* assert (TREE_VALUE (TYPE_ARG_TYPES (fntype)) == void_type_node); */
|
|
|
170 formal_list = "void";
|
|
|
171 else
|
|
|
172 formal_list = "/* ??? */";
|
|
|
173 }
|
|
|
174 else
|
|
|
175 {
|
|
|
176 /* If there were at least some parameters, and if the formals-types-list
|
|
|
177 petered out to a NULL (i.e. without being terminated by a
|
|
|
178 void_type_node) then we need to tack on an ellipsis. */
|
|
|
179 if (!formal_type)
|
|
|
180 formal_list = concat (formal_list, ", ...", NULL);
|
|
|
181 }
|
|
|
182
|
|
|
183 return concat (" (", formal_list, ")", NULL);
|
|
|
184 }
|
|
|
185
|
|
|
186 /* For the generation of an ANSI prototype for a function definition, we have
|
|
|
187 to look at the formal parameter list of the function's own "type" to
|
|
|
188 determine if the function's formal parameter list should end with an
|
|
|
189 ellipsis. Given a tree node, the following function will return nonzero
|
|
|
190 if the "function type" parameter list should end with an ellipsis. */
|
|
|
191
|
|
|
192 static int
|
|
|
193 deserves_ellipsis (tree fntype)
|
|
|
194 {
|
|
|
195 tree formal_type;
|
|
|
196
|
|
|
197 formal_type = TYPE_ARG_TYPES (fntype);
|
|
|
198 while (formal_type && TREE_VALUE (formal_type) != void_type_node)
|
|
|
199 formal_type = TREE_CHAIN (formal_type);
|
|
|
200
|
|
|
201 /* If there were at least some parameters, and if the formals-types-list
|
|
|
202 petered out to a NULL (i.e. without being terminated by a void_type_node)
|
|
|
203 then we need to tack on an ellipsis. */
|
|
|
204
|
|
|
205 return (!formal_type && TYPE_ARG_TYPES (fntype));
|
|
|
206 }
|
|
|
207
|
|
|
208 /* Generate a parameter list for a function definition (in some given style).
|
|
|
209
|
|
|
210 Note that this routine has to be separate (and different) from the code that
|
|
|
211 generates the prototype parameter lists for function declarations, because
|
|
|
212 in the case of a function declaration, all we have to go on is a tree node
|
|
|
213 representing the function's own "function type". This can tell us the types
|
|
|
214 of all of the formal parameters for the function, but it cannot tell us the
|
|
|
215 actual *names* of each of the formal parameters. We need to output those
|
|
|
216 parameter names for each function definition.
|
|
|
217
|
|
|
218 This routine gets a pointer to a tree node which represents the actual
|
|
|
219 declaration of the given function, and this DECL node has a list of formal
|
|
|
220 parameter (variable) declarations attached to it. These formal parameter
|
|
|
221 (variable) declaration nodes give us the actual names of the formal
|
|
|
222 parameters for the given function definition.
|
|
|
223
|
|
|
224 This routine returns a string which is the source form for the entire
|
|
|
225 function formal parameter list. */
|
|
|
226
|
|
|
227 static const char *
|
|
|
228 gen_formal_list_for_func_def (tree fndecl, formals_style style)
|
|
|
229 {
|
|
|
230 const char *formal_list = "";
|
|
|
231 tree formal_decl;
|
|
|
232
|
|
|
233 formal_decl = DECL_ARGUMENTS (fndecl);
|
|
|
234 while (formal_decl)
|
|
|
235 {
|
|
|
236 const char *this_formal;
|
|
|
237
|
|
|
238 if (*formal_list && ((style == ansi) || (style == k_and_r_names)))
|
|
|
239 formal_list = concat (formal_list, ", ", NULL);
|
|
|
240 this_formal = gen_decl (formal_decl, 0, style);
|
|
|
241 if (style == k_and_r_decls)
|
|
|
242 formal_list = concat (formal_list, this_formal, "; ", NULL);
|
|
|
243 else
|
|
|
244 formal_list = concat (formal_list, this_formal, NULL);
|
|
|
245 formal_decl = TREE_CHAIN (formal_decl);
|
|
|
246 }
|
|
|
247 if (style == ansi)
|
|
|
248 {
|
|
|
249 if (!DECL_ARGUMENTS (fndecl))
|
|
|
250 formal_list = concat (formal_list, "void", NULL);
|
|
|
251 if (deserves_ellipsis (TREE_TYPE (fndecl)))
|
|
|
252 formal_list = concat (formal_list, ", ...", NULL);
|
|
|
253 }
|
|
|
254 if ((style == ansi) || (style == k_and_r_names))
|
|
|
255 formal_list = concat (" (", formal_list, ")", NULL);
|
|
|
256 return formal_list;
|
|
|
257 }
|
|
|
258
|
|
|
259 /* Generate a string which is the source code form for a given type (t). This
|
|
|
260 routine is ugly and complex because the C syntax for declarations is ugly
|
|
|
261 and complex. This routine is straightforward so long as *no* pointer types,
|
|
|
262 array types, or function types are involved.
|
|
|
263
|
|
|
264 In the simple cases, this routine will return the (string) value which was
|
|
|
265 passed in as the "ret_val" argument. Usually, this starts out either as an
|
|
|
266 empty string, or as the name of the declared item (i.e. the formal function
|
|
|
267 parameter variable).
|
|
|
268
|
|
|
269 This routine will also return with the global variable "data_type" set to
|
|
|
270 some string value which is the "basic" data-type of the given complete type.
|
|
|
271 This "data_type" string can be concatenated onto the front of the returned
|
|
|
272 string after this routine returns to its caller.
|
|
|
273
|
|
|
274 In complicated cases involving pointer types, array types, or function
|
|
|
275 types, the C declaration syntax requires an "inside out" approach, i.e. if
|
|
|
276 you have a type which is a "pointer-to-function" type, you need to handle
|
|
|
277 the "pointer" part first, but it also has to be "innermost" (relative to
|
|
|
278 the declaration stuff for the "function" type). Thus, is this case, you
|
|
|
279 must prepend a "(*" and append a ")" to the name of the item (i.e. formal
|
|
|
280 variable). Then you must append and prepend the other info for the
|
|
|
281 "function type" part of the overall type.
|
|
|
282
|
|
|
283 To handle the "innermost precedence" rules of complicated C declarators, we
|
|
|
284 do the following (in this routine). The input parameter called "ret_val"
|
|
|
285 is treated as a "seed". Each time gen_type is called (perhaps recursively)
|
|
|
286 some additional strings may be appended or prepended (or both) to the "seed"
|
|
|
287 string. If yet another (lower) level of the GCC tree exists for the given
|
|
|
288 type (as in the case of a pointer type, an array type, or a function type)
|
|
|
289 then the (wrapped) seed is passed to a (recursive) invocation of gen_type()
|
|
|
290 this recursive invocation may again "wrap" the (new) seed with yet more
|
|
|
291 declarator stuff, by appending, prepending (or both). By the time the
|
|
|
292 recursion bottoms out, the "seed value" at that point will have a value
|
|
|
293 which is (almost) the complete source version of the declarator (except
|
|
|
294 for the data_type info). Thus, this deepest "seed" value is simply passed
|
|
|
295 back up through all of the recursive calls until it is given (as the return
|
|
|
296 value) to the initial caller of the gen_type() routine. All that remains
|
|
|
297 to do at this point is for the initial caller to prepend the "data_type"
|
|
|
298 string onto the returned "seed". */
|
|
|
299
|
|
|
300 static const char *
|
|
|
301 gen_type (const char *ret_val, tree t, formals_style style)
|
|
|
302 {
|
|
|
303 tree chain_p;
|
|
|
304
|
|
|
305 /* If there is a typedef name for this type, use it. */
|
|
|
306 if (TYPE_NAME (t) && TREE_CODE (TYPE_NAME (t)) == TYPE_DECL)
|
|
|
307 data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t)));
|
|
|
308 else
|
|
|
309 {
|
|
|
310 switch (TREE_CODE (t))
|
|
|
311 {
|
|
|
312 case POINTER_TYPE:
|
|
|
313 if (TYPE_READONLY (t))
|
|
|
314 ret_val = concat ("const ", ret_val, NULL);
|
|
|
315 if (TYPE_VOLATILE (t))
|
|
|
316 ret_val = concat ("volatile ", ret_val, NULL);
|
|
|
317
|
|
|
318 ret_val = concat ("*", ret_val, NULL);
|
|
|
319
|
|
|
320 if (TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE || TREE_CODE (TREE_TYPE (t)) == FUNCTION_TYPE)
|
|
|
321 ret_val = concat ("(", ret_val, ")", NULL);
|
|
|
322
|
|
|
323 ret_val = gen_type (ret_val, TREE_TYPE (t), style);
|
|
|
324
|
|
|
325 return ret_val;
|
|
|
326
|
|
|
327 case ARRAY_TYPE:
|
|
|
328 if (!COMPLETE_TYPE_P (t) || TREE_CODE (TYPE_SIZE (t)) != INTEGER_CST)
|
|
|
329 ret_val = gen_type (concat (ret_val, "[]", NULL),
|
|
|
330 TREE_TYPE (t), style);
|
|
|
331 else if (int_size_in_bytes (t) == 0)
|
|
|
332 ret_val = gen_type (concat (ret_val, "[0]", NULL),
|
|
|
333 TREE_TYPE (t), style);
|
|
|
334 else
|
|
|
335 {
|
|
|
336 int size = (int_size_in_bytes (t) / int_size_in_bytes (TREE_TYPE (t)));
|
|
|
337 char buff[10];
|
|
|
338 sprintf (buff, "[%d]", size);
|
|
|
339 ret_val = gen_type (concat (ret_val, buff, NULL),
|
|
|
340 TREE_TYPE (t), style);
|
|
|
341 }
|
|
|
342 break;
|
|
|
343
|
|
|
344 case FUNCTION_TYPE:
|
|
|
345 ret_val = gen_type (concat (ret_val,
|
|
|
346 gen_formal_list_for_type (t, style),
|
|
|
347 NULL),
|
|
|
348 TREE_TYPE (t), style);
|
|
|
349 break;
|
|
|
350
|
|
|
351 case IDENTIFIER_NODE:
|
|
|
352 data_type = IDENTIFIER_POINTER (t);
|
|
|
353 break;
|
|
|
354
|
|
|
355 /* The following three cases are complicated by the fact that a
|
|
|
356 user may do something really stupid, like creating a brand new
|
|
|
357 "anonymous" type specification in a formal argument list (or as
|
|
|
358 part of a function return type specification). For example:
|
|
|
359
|
|
|
360 int f (enum { red, green, blue } color);
|
|
|
361
|
|
|
362 In such cases, we have no name that we can put into the prototype
|
|
|
363 to represent the (anonymous) type. Thus, we have to generate the
|
|
|
364 whole darn type specification. Yuck! */
|
|
|
365
|
|
|
366 case RECORD_TYPE:
|
|
|
367 if (TYPE_NAME (t))
|
|
|
368 data_type = IDENTIFIER_POINTER (TYPE_NAME (t));
|
|
|
369 else
|
|
|
370 {
|
|
|
371 data_type = "";
|
|
|
372 chain_p = TYPE_FIELDS (t);
|
|
|
373 while (chain_p)
|
|
|
374 {
|
|
|
375 data_type = concat (data_type, gen_decl (chain_p, 0, ansi),
|
|
|
376 NULL);
|
|
|
377 chain_p = TREE_CHAIN (chain_p);
|
|
|
378 data_type = concat (data_type, "; ", NULL);
|
|
|
379 }
|
|
|
380 data_type = concat ("{ ", data_type, "}", NULL);
|
|
|
381 }
|
|
|
382 data_type = concat ("struct ", data_type, NULL);
|
|
|
383 break;
|
|
|
384
|
|
|
385 case UNION_TYPE:
|
|
|
386 if (TYPE_NAME (t))
|
|
|
387 data_type = IDENTIFIER_POINTER (TYPE_NAME (t));
|
|
|
388 else
|
|
|
389 {
|
|
|
390 data_type = "";
|
|
|
391 chain_p = TYPE_FIELDS (t);
|
|
|
392 while (chain_p)
|
|
|
393 {
|
|
|
394 data_type = concat (data_type, gen_decl (chain_p, 0, ansi),
|
|
|
395 NULL);
|
|
|
396 chain_p = TREE_CHAIN (chain_p);
|
|
|
397 data_type = concat (data_type, "; ", NULL);
|
|
|
398 }
|
|
|
399 data_type = concat ("{ ", data_type, "}", NULL);
|
|
|
400 }
|
|
|
401 data_type = concat ("union ", data_type, NULL);
|
|
|
402 break;
|
|
|
403
|
|
|
404 case ENUMERAL_TYPE:
|
|
|
405 if (TYPE_NAME (t))
|
|
|
406 data_type = IDENTIFIER_POINTER (TYPE_NAME (t));
|
|
|
407 else
|
|
|
408 {
|
|
|
409 data_type = "";
|
|
|
410 chain_p = TYPE_VALUES (t);
|
|
|
411 while (chain_p)
|
|
|
412 {
|
|
|
413 data_type = concat (data_type,
|
|
|
414 IDENTIFIER_POINTER (TREE_PURPOSE (chain_p)), NULL);
|
|
|
415 chain_p = TREE_CHAIN (chain_p);
|
|
|
416 if (chain_p)
|
|
|
417 data_type = concat (data_type, ", ", NULL);
|
|
|
418 }
|
|
|
419 data_type = concat ("{ ", data_type, " }", NULL);
|
|
|
420 }
|
|
|
421 data_type = concat ("enum ", data_type, NULL);
|
|
|
422 break;
|
|
|
423
|
|
|
424 case TYPE_DECL:
|
|
|
425 data_type = IDENTIFIER_POINTER (DECL_NAME (t));
|
|
|
426 break;
|
|
|
427
|
|
|
428 case INTEGER_TYPE:
|
|
|
429 case FIXED_POINT_TYPE:
|
|
|
430 data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t)));
|
|
|
431 /* Normally, `unsigned' is part of the deal. Not so if it comes
|
|
|
432 with a type qualifier. */
|
|
|
433 if (TYPE_UNSIGNED (t) && TYPE_QUALS (t))
|
|
|
434 data_type = concat ("unsigned ", data_type, NULL);
|
|
|
435 break;
|
|
|
436
|
|
|
437 case REAL_TYPE:
|
|
|
438 data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t)));
|
|
|
439 break;
|
|
|
440
|
|
|
441 case VOID_TYPE:
|
|
|
442 data_type = "void";
|
|
|
443 break;
|
|
|
444
|
|
|
445 case ERROR_MARK:
|
|
|
446 data_type = "[ERROR]";
|
|
|
447 break;
|
|
|
448
|
|
|
449 default:
|
|
|
450 gcc_unreachable ();
|
|
|
451 }
|
|
|
452 }
|
|
|
453 if (TYPE_READONLY (t))
|
|
|
454 ret_val = concat ("const ", ret_val, NULL);
|
|
|
455 if (TYPE_VOLATILE (t))
|
|
|
456 ret_val = concat ("volatile ", ret_val, NULL);
|
|
|
457 if (TYPE_RESTRICT (t))
|
|
|
458 ret_val = concat ("restrict ", ret_val, NULL);
|
|
|
459 return ret_val;
|
|
|
460 }
|
|
|
461
|
|
|
462 /* Generate a string (source) representation of an entire entity declaration
|
|
|
463 (using some particular style for function types).
|
|
|
464
|
|
|
465 The given entity may be either a variable or a function.
|
|
|
466
|
|
|
467 If the "is_func_definition" parameter is nonzero, assume that the thing
|
|
|
468 we are generating a declaration for is a FUNCTION_DECL node which is
|
|
|
469 associated with a function definition. In this case, we can assume that
|
|
|
470 an attached list of DECL nodes for function formal arguments is present. */
|
|
|
471
|
|
|
472 static const char *
|
|
|
473 gen_decl (tree decl, int is_func_definition, formals_style style)
|
|
|
474 {
|
|
|
475 const char *ret_val;
|
|
|
476
|
|
|
477 if (DECL_NAME (decl))
|
|
|
478 ret_val = IDENTIFIER_POINTER (DECL_NAME (decl));
|
|
|
479 else
|
|
|
480 ret_val = "";
|
|
|
481
|
|
|
482 /* If we are just generating a list of names of formal parameters, we can
|
|
|
483 simply return the formal parameter name (with no typing information
|
|
|
484 attached to it) now. */
|
|
|
485
|
|
|
486 if (style == k_and_r_names)
|
|
|
487 return ret_val;
|
|
|
488
|
|
|
489 /* Note that for the declaration of some entity (either a function or a
|
|
|
490 data object, like for instance a parameter) if the entity itself was
|
|
|
491 declared as either const or volatile, then const and volatile properties
|
|
|
492 are associated with just the declaration of the entity, and *not* with
|
|
|
493 the `type' of the entity. Thus, for such declared entities, we have to
|
|
|
494 generate the qualifiers here. */
|
|
|
495
|
|
|
496 if (TREE_THIS_VOLATILE (decl))
|
|
|
497 ret_val = concat ("volatile ", ret_val, NULL);
|
|
|
498 if (TREE_READONLY (decl))
|
|
|
499 ret_val = concat ("const ", ret_val, NULL);
|
|
|
500
|
|
|
501 data_type = "";
|
|
|
502
|
|
|
503 /* For FUNCTION_DECL nodes, there are two possible cases here. First, if
|
|
|
504 this FUNCTION_DECL node was generated from a function "definition", then
|
|
|
505 we will have a list of DECL_NODE's, one for each of the function's formal
|
|
|
506 parameters. In this case, we can print out not only the types of each
|
|
|
507 formal, but also each formal's name. In the second case, this
|
|
|
508 FUNCTION_DECL node came from an actual function declaration (and *not*
|
|
|
509 a definition). In this case, we do nothing here because the formal
|
|
|
510 argument type-list will be output later, when the "type" of the function
|
|
|
511 is added to the string we are building. Note that the ANSI-style formal
|
|
|
512 parameter list is considered to be a (suffix) part of the "type" of the
|
|
|
513 function. */
|
|
|
514
|
|
|
515 if (TREE_CODE (decl) == FUNCTION_DECL && is_func_definition)
|
|
|
516 {
|
|
|
517 ret_val = concat (ret_val, gen_formal_list_for_func_def (decl, ansi),
|
|
|
518 NULL);
|
|
|
519
|
|
|
520 /* Since we have already added in the formals list stuff, here we don't
|
|
|
521 add the whole "type" of the function we are considering (which
|
|
|
522 would include its parameter-list info), rather, we only add in
|
|
|
523 the "type" of the "type" of the function, which is really just
|
|
|
524 the return-type of the function (and does not include the parameter
|
|
|
525 list info). */
|
|
|
526
|
|
|
527 ret_val = gen_type (ret_val, TREE_TYPE (TREE_TYPE (decl)), style);
|
|
|
528 }
|
|
|
529 else
|
|
|
530 ret_val = gen_type (ret_val, TREE_TYPE (decl), style);
|
|
|
531
|
|
|
532 ret_val = affix_data_type (ret_val);
|
|
|
533
|
|
|
534 if (TREE_CODE (decl) != FUNCTION_DECL && C_DECL_REGISTER (decl))
|
|
|
535 ret_val = concat ("register ", ret_val, NULL);
|
|
|
536 if (TREE_PUBLIC (decl))
|
|
|
537 ret_val = concat ("extern ", ret_val, NULL);
|
|
|
538 if (TREE_CODE (decl) == FUNCTION_DECL && !TREE_PUBLIC (decl))
|
|
|
539 ret_val = concat ("static ", ret_val, NULL);
|
|
|
540
|
|
|
541 return ret_val;
|
|
|
542 }
|
|
|
543
|
|
|
544 extern FILE *aux_info_file;
|
|
|
545
|
|
|
546 /* Generate and write a new line of info to the aux-info (.X) file. This
|
|
|
547 routine is called once for each function declaration, and once for each
|
|
|
548 function definition (even the implicit ones). */
|
|
|
549
|
|
|
550 void
|
|
|
551 gen_aux_info_record (tree fndecl, int is_definition, int is_implicit,
|
|
|
552 int is_prototyped)
|
|
|
553 {
|
|
|
554 if (flag_gen_aux_info)
|
|
|
555 {
|
|
|
556 static int compiled_from_record = 0;
|
|
|
557 expanded_location xloc = expand_location (DECL_SOURCE_LOCATION (fndecl));
|
|
|
558
|
|
|
559 /* Each output .X file must have a header line. Write one now if we
|
|
|
560 have not yet done so. */
|
|
|
561
|
|
|
562 if (!compiled_from_record++)
|
|
|
563 {
|
|
|
564 /* The first line tells which directory file names are relative to.
|
|
|
565 Currently, -aux-info works only for files in the working
|
|
|
566 directory, so just use a `.' as a placeholder for now. */
|
|
|
567 fprintf (aux_info_file, "/* compiled from: . */\n");
|
|
|
568 }
|
|
|
569
|
|
|
570 /* Write the actual line of auxiliary info. */
|
|
|
571
|
|
|
572 fprintf (aux_info_file, "/* %s:%d:%c%c */ %s;",
|
|
|
573 xloc.file, xloc.line,
|
|
|
574 (is_implicit) ? 'I' : (is_prototyped) ? 'N' : 'O',
|
|
|
575 (is_definition) ? 'F' : 'C',
|
|
|
576 gen_decl (fndecl, is_definition, ansi));
|
|
|
577
|
|
|
578 /* If this is an explicit function declaration, we need to also write
|
|
|
579 out an old-style (i.e. K&R) function header, just in case the user
|
|
|
580 wants to run unprotoize. */
|
|
|
581
|
|
|
582 if (is_definition)
|
|
|
583 {
|
|
|
584 fprintf (aux_info_file, " /*%s %s*/",
|
|
|
585 gen_formal_list_for_func_def (fndecl, k_and_r_names),
|
|
|
586 gen_formal_list_for_func_def (fndecl, k_and_r_decls));
|
|
|
587 }
|
|
|
588
|
|
|
589 fprintf (aux_info_file, "\n");
|
|
|
590 }
|
|
|
591 }
|
