Mercurial > hg > CbC > CbC_gcc
comparison gcc/c-aux-info.c @ 0:a06113de4d67
first commit
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 17 Jul 2009 14:47:48 +0900 |
parents | |
children | f6334be47118 |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:a06113de4d67 |
---|---|
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 } |