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