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