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