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