gcc/c-aux-info.c

   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
   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 2, 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 COPYING.  If not, write to the Free
  22 Software Foundation, 59 Temple Place - Suite 330, Boston, MA
  23 02111-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
  32 enum formals_style_enum {
  33   ansi,
  34   k_and_r_names,
  35   k_and_r_decls
  36 };
  37 typedef enum formals_style_enum formals_style;
  38
  39
  40 static const char *data_type;
  41
  42 static char *affix_data_type            PARAMS ((const char *)) ATTRIBUTE_MALLOC;
  43 static const char *gen_formal_list_for_type PARAMS ((tree, formals_style));
  44 static int   deserves_ellipsis          PARAMS ((tree));
  45 static const char *gen_formal_list_for_func_def PARAMS ((tree, formals_style));
  46 static const char *gen_type             PARAMS ((const char *, tree, formals_style));
  47 static const char *gen_decl             PARAMS ((tree, int, formals_style));
  48 \f
  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
  63 static char *
  64 affix_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
 110 static const char *
 111 gen_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
 194 static int
 195 deserves_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
 230 static const char *
 231 gen_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
 305 static const char *
 306 gen_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
 479 static const char *
 480 gen_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
 554 extern 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
 560 void
 561 gen_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 }