c-aux-info.c revision 18334
139833Speter/* Generate information regarding function declarations and definitions based 239833Speter on information stored in GCC's tree structure. This code implements the 339833Speter -aux-info option. 439833Speter Copyright (C) 1989, 1991, 1994, 1995 Free Software Foundation, Inc. 539833Speter Contributed by Ron Guilmette (rfg@segfault.us.com). 639833Speter 739833SpeterThis file is part of GNU CC. 839833Speter 939833SpeterGNU CC is free software; you can redistribute it and/or modify 1039833Speterit under the terms of the GNU General Public License as published by 1139833Speterthe Free Software Foundation; either version 2, or (at your option) 1239833Speterany later version. 1339833Speter 1439833SpeterGNU CC is distributed in the hope that it will be useful, 1539833Speterbut WITHOUT ANY WARRANTY; without even the implied warranty of 1639833SpeterMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 1739833SpeterGNU General Public License for more details. 1839833Speter 1939833SpeterYou should have received a copy of the GNU General Public License 2039833Speteralong with GNU CC; see the file COPYING. If not, write to 2139833Speterthe Free Software Foundation, 59 Temple Place - Suite 330, 2239833SpeterBoston, MA 02111-1307, USA. */ 2339833Speter 2439833Speter#include <stdio.h> 2539833Speter#include "config.h" 2639833Speter#include "flags.h" 2739833Speter#include "tree.h" 2839833Speter#include "c-tree.h" 2939833Speter 3039833Speterextern char* xmalloc (); 3139833Speter 3239833Speterenum formals_style_enum { 3339833Speter ansi, 3439833Speter k_and_r_names, 3539833Speter k_and_r_decls 3639833Speter}; 3739833Spetertypedef enum formals_style_enum formals_style; 3839833Speter 3939833Speter 4039833Speterstatic char* data_type; 4139833Speter 4239833Speterstatic char * concat (); 4339833Speterstatic char * concat3 (); 4439833Speterstatic char * gen_formal_list_for_type (); 4539833Speterstatic int deserves_ellipsis (); 4639833Speterstatic char * gen_formal_list_for_func_def (); 4739833Speterstatic char * gen_type (); 4839833Speterstatic char * gen_decl (); 4939833Spetervoid gen_aux_info_record (); 5039833Speter 5139833Speter/* Take two strings and mash them together into a newly allocated area. */ 5239833Speter 5339833Speterstatic char* 5439833Speterconcat (s1, s2) 5539833Speter char* s1; 5639833Speter char* s2; 5739833Speter{ 5839833Speter int size1, size2; 5939833Speter char* ret_val; 6039833Speter 6139833Speter if (!s1) 6239833Speter s1 = ""; 6339833Speter if (!s2) 6439833Speter s2 = ""; 6539833Speter 6639833Speter size1 = strlen (s1); 6739833Speter size2 = strlen (s2); 6839833Speter ret_val = xmalloc (size1 + size2 + 1); 6939833Speter strcpy (ret_val, s1); 7039833Speter strcpy (&ret_val[size1], s2); 7139833Speter return ret_val; 7239833Speter} 7339833Speter 7439833Speter/* Take three strings and mash them together into a newly allocated area. */ 7539833Speter 7639833Speterstatic char* 7739833Speterconcat3 (s1, s2, s3) 7839833Speter char* s1; 7939833Speter char* s2; 8039833Speter char* s3; 8139833Speter{ 8239833Speter int size1, size2, size3; 8339833Speter char* ret_val; 8439833Speter 8539833Speter if (!s1) 8639833Speter s1 = ""; 8739833Speter if (!s2) 8839833Speter s2 = ""; 8939833Speter if (!s3) 9039833Speter s3 = ""; 9139833Speter 9239833Speter size1 = strlen (s1); 9339833Speter size2 = strlen (s2); 9439833Speter size3 = strlen (s3); 9539833Speter ret_val = xmalloc (size1 + size2 + size3 + 1); 9639833Speter strcpy (ret_val, s1); 9739833Speter strcpy (&ret_val[size1], s2); 9839833Speter strcpy (&ret_val[size1+size2], s3); 9939833Speter return ret_val; 10039833Speter} 10139833Speter 10239833Speter/* Given a string representing an entire type or an entire declaration 10339833Speter which only lacks the actual "data-type" specifier (at its left end), 10439833Speter affix the data-type specifier to the left end of the given type 10539833Speter specification or object declaration. 10639833Speter 10739833Speter Because of C language weirdness, the data-type specifier (which normally 10839833Speter goes in at the very left end) may have to be slipped in just to the 10939833Speter right of any leading "const" or "volatile" qualifiers (there may be more 11039833Speter than one). Actually this may not be strictly necessary because it seems 11139833Speter that GCC (at least) accepts `<data-type> const foo;' and treats it the 11239833Speter same as `const <data-type> foo;' but people are accustomed to seeing 11339833Speter `const char *foo;' and *not* `char const *foo;' so we try to create types 11439833Speter that look as expected. */ 11539833Speter 11639833Speterstatic char* 11739833Speteraffix_data_type (type_or_decl) 11839833Speter char *type_or_decl; 11939833Speter{ 12039833Speter char *p = type_or_decl; 12139833Speter char *qualifiers_then_data_type; 12239833Speter char saved; 12339833Speter 12439833Speter /* Skip as many leading const's or volatile's as there are. */ 12539833Speter 12639833Speter for (;;) 12739833Speter { 12839833Speter if (!strncmp (p, "volatile ", 9)) 12939833Speter { 13039833Speter p += 9; 13139833Speter continue; 13239833Speter } 13339833Speter if (!strncmp (p, "const ", 6)) 13439833Speter { 13539833Speter p += 6; 13639833Speter continue; 13739833Speter } 13839833Speter break; 13939833Speter } 14039833Speter 14139833Speter /* p now points to the place where we can insert the data type. We have to 14239833Speter add a blank after the data-type of course. */ 14339833Speter 14439833Speter if (p == type_or_decl) 14539833Speter return concat3 (data_type, " ", type_or_decl); 14639833Speter 14739833Speter saved = *p; 14839833Speter *p = '\0'; 14939833Speter qualifiers_then_data_type = concat (type_or_decl, data_type); 15039833Speter *p = saved; 15139833Speter return concat3 (qualifiers_then_data_type, " ", p); 15239833Speter} 15339833Speter 15439833Speter/* Given a tree node which represents some "function type", generate the 15539833Speter source code version of a formal parameter list (of some given style) for 15639833Speter this function type. Return the whole formal parameter list (including 15739833Speter a pair of surrounding parens) as a string. Note that if the style 15839833Speter we are currently aiming for is non-ansi, then we just return a pair 15939833Speter of empty parens here. */ 16039833Speter 16139833Speterstatic char* 16239833Spetergen_formal_list_for_type (fntype, style) 16339833Speter tree fntype; 16439833Speter formals_style style; 16539833Speter{ 16639833Speter char* formal_list = ""; 16739833Speter tree formal_type; 16839833Speter 16939833Speter if (style != ansi) 17039833Speter return "()"; 17139833Speter 17239833Speter formal_type = TYPE_ARG_TYPES (fntype); 17339833Speter while (formal_type && TREE_VALUE (formal_type) != void_type_node) 174 { 175 char* this_type; 176 177 if (*formal_list) 178 formal_list = concat (formal_list, ", "); 179 180 this_type = gen_type ("", TREE_VALUE (formal_type), ansi); 181 formal_list = 182 (strlen (this_type)) 183 ? concat (formal_list, affix_data_type (this_type)) 184 : concat (formal_list, data_type); 185 186 formal_type = TREE_CHAIN (formal_type); 187 } 188 189 /* If we got to here, then we are trying to generate an ANSI style formal 190 parameters list. 191 192 New style prototyped ANSI formal parameter lists should in theory always 193 contain some stuff between the opening and closing parens, even if it is 194 only "void". 195 196 The brutal truth though is that there is lots of old K&R code out there 197 which contains declarations of "pointer-to-function" parameters and 198 these almost never have fully specified formal parameter lists associated 199 with them. That is, the pointer-to-function parameters are declared 200 with just empty parameter lists. 201 202 In cases such as these, protoize should really insert *something* into 203 the vacant parameter lists, but what? It has no basis on which to insert 204 anything in particular. 205 206 Here, we make life easy for protoize by trying to distinguish between 207 K&R empty parameter lists and new-style prototyped parameter lists 208 that actually contain "void". In the latter case we (obviously) want 209 to output the "void" verbatim, and that what we do. In the former case, 210 we do our best to give protoize something nice to insert. 211 212 This "something nice" should be something that is still valid (when 213 re-compiled) but something that can clearly indicate to the user that 214 more typing information (for the parameter list) should be added (by 215 hand) at some convenient moment. 216 217 The string chosen here is a comment with question marks in it. */ 218 219 if (!*formal_list) 220 { 221 if (TYPE_ARG_TYPES (fntype)) 222 /* assert (TREE_VALUE (TYPE_ARG_TYPES (fntype)) == void_type_node); */ 223 formal_list = "void"; 224 else 225 formal_list = "/* ??? */"; 226 } 227 else 228 { 229 /* If there were at least some parameters, and if the formals-types-list 230 petered out to a NULL (i.e. without being terminated by a 231 void_type_node) then we need to tack on an ellipsis. */ 232 if (!formal_type) 233 formal_list = concat (formal_list, ", ..."); 234 } 235 236 return concat3 (" (", formal_list, ")"); 237} 238 239/* For the generation of an ANSI prototype for a function definition, we have 240 to look at the formal parameter list of the function's own "type" to 241 determine if the function's formal parameter list should end with an 242 ellipsis. Given a tree node, the following function will return non-zero 243 if the "function type" parameter list should end with an ellipsis. */ 244 245static int 246deserves_ellipsis (fntype) 247 tree fntype; 248{ 249 tree formal_type; 250 251 formal_type = TYPE_ARG_TYPES (fntype); 252 while (formal_type && TREE_VALUE (formal_type) != void_type_node) 253 formal_type = TREE_CHAIN (formal_type); 254 255 /* If there were at least some parameters, and if the formals-types-list 256 petered out to a NULL (i.e. without being terminated by a void_type_node) 257 then we need to tack on an ellipsis. */ 258 259 return (!formal_type && TYPE_ARG_TYPES (fntype)); 260} 261 262/* Generate a parameter list for a function definition (in some given style). 263 264 Note that this routine has to be separate (and different) from the code that 265 generates the prototype parameter lists for function declarations, because 266 in the case of a function declaration, all we have to go on is a tree node 267 representing the function's own "function type". This can tell us the types 268 of all of the formal parameters for the function, but it cannot tell us the 269 actual *names* of each of the formal parameters. We need to output those 270 parameter names for each function definition. 271 272 This routine gets a pointer to a tree node which represents the actual 273 declaration of the given function, and this DECL node has a list of formal 274 parameter (variable) declarations attached to it. These formal parameter 275 (variable) declaration nodes give us the actual names of the formal 276 parameters for the given function definition. 277 278 This routine returns a string which is the source form for the entire 279 function formal parameter list. */ 280 281static char* 282gen_formal_list_for_func_def (fndecl, style) 283 tree fndecl; 284 formals_style style; 285{ 286 char* formal_list = ""; 287 tree formal_decl; 288 289 formal_decl = DECL_ARGUMENTS (fndecl); 290 while (formal_decl) 291 { 292 char *this_formal; 293 294 if (*formal_list && ((style == ansi) || (style == k_and_r_names))) 295 formal_list = concat (formal_list, ", "); 296 this_formal = gen_decl (formal_decl, 0, style); 297 if (style == k_and_r_decls) 298 formal_list = concat3 (formal_list, this_formal, "; "); 299 else 300 formal_list = concat (formal_list, this_formal); 301 formal_decl = TREE_CHAIN (formal_decl); 302 } 303 if (style == ansi) 304 { 305 if (!DECL_ARGUMENTS (fndecl)) 306 formal_list = concat (formal_list, "void"); 307 if (deserves_ellipsis (TREE_TYPE (fndecl))) 308 formal_list = concat (formal_list, ", ..."); 309 } 310 if ((style == ansi) || (style == k_and_r_names)) 311 formal_list = concat3 (" (", formal_list, ")"); 312 return formal_list; 313} 314 315/* Generate a string which is the source code form for a given type (t). This 316 routine is ugly and complex because the C syntax for declarations is ugly 317 and complex. This routine is straightforward so long as *no* pointer types, 318 array types, or function types are involved. 319 320 In the simple cases, this routine will return the (string) value which was 321 passed in as the "ret_val" argument. Usually, this starts out either as an 322 empty string, or as the name of the declared item (i.e. the formal function 323 parameter variable). 324 325 This routine will also return with the global variable "data_type" set to 326 some string value which is the "basic" data-type of the given complete type. 327 This "data_type" string can be concatenated onto the front of the returned 328 string after this routine returns to its caller. 329 330 In complicated cases involving pointer types, array types, or function 331 types, the C declaration syntax requires an "inside out" approach, i.e. if 332 you have a type which is a "pointer-to-function" type, you need to handle 333 the "pointer" part first, but it also has to be "innermost" (relative to 334 the declaration stuff for the "function" type). Thus, is this case, you 335 must prepend a "(*" and append a ")" to the name of the item (i.e. formal 336 variable). Then you must append and prepend the other info for the 337 "function type" part of the overall type. 338 339 To handle the "innermost precedence" rules of complicated C declarators, we 340 do the following (in this routine). The input parameter called "ret_val" 341 is treated as a "seed". Each time gen_type is called (perhaps recursively) 342 some additional strings may be appended or prepended (or both) to the "seed" 343 string. If yet another (lower) level of the GCC tree exists for the given 344 type (as in the case of a pointer type, an array type, or a function type) 345 then the (wrapped) seed is passed to a (recursive) invocation of gen_type() 346 this recursive invocation may again "wrap" the (new) seed with yet more 347 declarator stuff, by appending, prepending (or both). By the time the 348 recursion bottoms out, the "seed value" at that point will have a value 349 which is (almost) the complete source version of the declarator (except 350 for the data_type info). Thus, this deepest "seed" value is simply passed 351 back up through all of the recursive calls until it is given (as the return 352 value) to the initial caller of the gen_type() routine. All that remains 353 to do at this point is for the initial caller to prepend the "data_type" 354 string onto the returned "seed". */ 355 356static char* 357gen_type (ret_val, t, style) 358 char* ret_val; 359 tree t; 360 formals_style style; 361{ 362 tree chain_p; 363 364 if (TYPE_NAME (t) && DECL_NAME (TYPE_NAME (t))) 365 data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t))); 366 else 367 { 368 switch (TREE_CODE (t)) 369 { 370 case POINTER_TYPE: 371 if (TYPE_READONLY (t)) 372 ret_val = concat ("const ", ret_val); 373 if (TYPE_VOLATILE (t)) 374 ret_val = concat ("volatile ", ret_val); 375 376 ret_val = concat ("*", ret_val); 377 378 if (TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE || TREE_CODE (TREE_TYPE (t)) == FUNCTION_TYPE) 379 ret_val = concat3 ("(", ret_val, ")"); 380 381 ret_val = gen_type (ret_val, TREE_TYPE (t), style); 382 383 return ret_val; 384 385 case ARRAY_TYPE: 386 if (TYPE_SIZE (t) == 0 || TREE_CODE (TYPE_SIZE (t)) != INTEGER_CST) 387 ret_val = gen_type (concat (ret_val, "[]"), TREE_TYPE (t), style); 388 else if (int_size_in_bytes (t) == 0) 389 ret_val = gen_type (concat (ret_val, "[0]"), TREE_TYPE (t), style); 390 else 391 { 392 int size = (int_size_in_bytes (t) / int_size_in_bytes (TREE_TYPE (t))); 393 char buff[10]; 394 sprintf (buff, "[%d]", size); 395 ret_val = gen_type (concat (ret_val, buff), 396 TREE_TYPE (t), style); 397 } 398 break; 399 400 case FUNCTION_TYPE: 401 ret_val = gen_type (concat (ret_val, gen_formal_list_for_type (t, style)), TREE_TYPE (t), style); 402 break; 403 404 case IDENTIFIER_NODE: 405 data_type = IDENTIFIER_POINTER (t); 406 break; 407 408 /* The following three cases are complicated by the fact that a 409 user may do something really stupid, like creating a brand new 410 "anonymous" type specification in a formal argument list (or as 411 part of a function return type specification). For example: 412 413 int f (enum { red, green, blue } color); 414 415 In such cases, we have no name that we can put into the prototype 416 to represent the (anonymous) type. Thus, we have to generate the 417 whole darn type specification. Yuck! */ 418 419 case RECORD_TYPE: 420 if (TYPE_NAME (t)) 421 data_type = IDENTIFIER_POINTER (TYPE_NAME (t)); 422 else 423 { 424 data_type = ""; 425 chain_p = TYPE_FIELDS (t); 426 while (chain_p) 427 { 428 data_type = concat (data_type, gen_decl (chain_p, 0, ansi)); 429 chain_p = TREE_CHAIN (chain_p); 430 data_type = concat (data_type, "; "); 431 } 432 data_type = concat3 ("{ ", data_type, "}"); 433 } 434 data_type = concat ("struct ", data_type); 435 break; 436 437 case UNION_TYPE: 438 if (TYPE_NAME (t)) 439 data_type = IDENTIFIER_POINTER (TYPE_NAME (t)); 440 else 441 { 442 data_type = ""; 443 chain_p = TYPE_FIELDS (t); 444 while (chain_p) 445 { 446 data_type = concat (data_type, gen_decl (chain_p, 0, ansi)); 447 chain_p = TREE_CHAIN (chain_p); 448 data_type = concat (data_type, "; "); 449 } 450 data_type = concat3 ("{ ", data_type, "}"); 451 } 452 data_type = concat ("union ", data_type); 453 break; 454 455 case ENUMERAL_TYPE: 456 if (TYPE_NAME (t)) 457 data_type = IDENTIFIER_POINTER (TYPE_NAME (t)); 458 else 459 { 460 data_type = ""; 461 chain_p = TYPE_VALUES (t); 462 while (chain_p) 463 { 464 data_type = concat (data_type, 465 IDENTIFIER_POINTER (TREE_PURPOSE (chain_p))); 466 chain_p = TREE_CHAIN (chain_p); 467 if (chain_p) 468 data_type = concat (data_type, ", "); 469 } 470 data_type = concat3 ("{ ", data_type, " }"); 471 } 472 data_type = concat ("enum ", data_type); 473 break; 474 475 case TYPE_DECL: 476 data_type = IDENTIFIER_POINTER (DECL_NAME (t)); 477 break; 478 479 case INTEGER_TYPE: 480 data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t))); 481 /* Normally, `unsigned' is part of the deal. Not so if it comes 482 with `const' or `volatile'. */ 483 if (TREE_UNSIGNED (t) && (TYPE_READONLY (t) || TYPE_VOLATILE (t))) 484 data_type = concat ("unsigned ", data_type); 485 break; 486 487 case REAL_TYPE: 488 data_type = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (t))); 489 break; 490 491 case VOID_TYPE: 492 data_type = "void"; 493 break; 494 495 case ERROR_MARK: 496 data_type = "[ERROR]"; 497 break; 498 499 default: 500 abort (); 501 } 502 } 503 if (TYPE_READONLY (t)) 504 ret_val = concat ("const ", ret_val); 505 if (TYPE_VOLATILE (t)) 506 ret_val = concat ("volatile ", ret_val); 507 return ret_val; 508} 509 510/* Generate a string (source) representation of an entire entity declaration 511 (using some particular style for function types). 512 513 The given entity may be either a variable or a function. 514 515 If the "is_func_definition" parameter is non-zero, assume that the thing 516 we are generating a declaration for is a FUNCTION_DECL node which is 517 associated with a function definition. In this case, we can assume that 518 an attached list of DECL nodes for function formal arguments is present. */ 519 520static char* 521gen_decl (decl, is_func_definition, style) 522 tree decl; 523 int is_func_definition; 524 formals_style style; 525{ 526 char* ret_val; 527 528 if (DECL_NAME (decl)) 529 ret_val = IDENTIFIER_POINTER (DECL_NAME (decl)); 530 else 531 ret_val = ""; 532 533 /* If we are just generating a list of names of formal parameters, we can 534 simply return the formal parameter name (with no typing information 535 attached to it) now. */ 536 537 if (style == k_and_r_names) 538 return ret_val; 539 540 /* Note that for the declaration of some entity (either a function or a 541 data object, like for instance a parameter) if the entity itself was 542 declared as either const or volatile, then const and volatile properties 543 are associated with just the declaration of the entity, and *not* with 544 the `type' of the entity. Thus, for such declared entities, we have to 545 generate the qualifiers here. */ 546 547 if (TREE_THIS_VOLATILE (decl)) 548 ret_val = concat ("volatile ", ret_val); 549 if (TREE_READONLY (decl)) 550 ret_val = concat ("const ", ret_val); 551 552 data_type = ""; 553 554 /* For FUNCTION_DECL nodes, there are two possible cases here. First, if 555 this FUNCTION_DECL node was generated from a function "definition", then 556 we will have a list of DECL_NODE's, one for each of the function's formal 557 parameters. In this case, we can print out not only the types of each 558 formal, but also each formal's name. In the second case, this 559 FUNCTION_DECL node came from an actual function declaration (and *not* 560 a definition). In this case, we do nothing here because the formal 561 argument type-list will be output later, when the "type" of the function 562 is added to the string we are building. Note that the ANSI-style formal 563 parameter list is considered to be a (suffix) part of the "type" of the 564 function. */ 565 566 if (TREE_CODE (decl) == FUNCTION_DECL && is_func_definition) 567 { 568 ret_val = concat (ret_val, gen_formal_list_for_func_def (decl, ansi)); 569 570 /* Since we have already added in the formals list stuff, here we don't 571 add the whole "type" of the function we are considering (which 572 would include its parameter-list info), rather, we only add in 573 the "type" of the "type" of the function, which is really just 574 the return-type of the function (and does not include the parameter 575 list info). */ 576 577 ret_val = gen_type (ret_val, TREE_TYPE (TREE_TYPE (decl)), style); 578 } 579 else 580 ret_val = gen_type (ret_val, TREE_TYPE (decl), style); 581 582 ret_val = affix_data_type (ret_val); 583 584 if (DECL_REGISTER (decl)) 585 ret_val = concat ("register ", ret_val); 586 if (TREE_PUBLIC (decl)) 587 ret_val = concat ("extern ", ret_val); 588 if (TREE_CODE (decl) == FUNCTION_DECL && !TREE_PUBLIC (decl)) 589 ret_val = concat ("static ", ret_val); 590 591 return ret_val; 592} 593 594extern FILE* aux_info_file; 595 596/* Generate and write a new line of info to the aux-info (.X) file. This 597 routine is called once for each function declaration, and once for each 598 function definition (even the implicit ones). */ 599 600void 601gen_aux_info_record (fndecl, is_definition, is_implicit, is_prototyped) 602 tree fndecl; 603 int is_definition; 604 int is_implicit; 605 int is_prototyped; 606{ 607 if (flag_gen_aux_info) 608 { 609 static int compiled_from_record = 0; 610 611 /* Each output .X file must have a header line. Write one now if we 612 have not yet done so. */ 613 614 if (! compiled_from_record++) 615 { 616 /* The first line tells which directory file names are relative to. 617 Currently, -aux-info works only for files in the working 618 directory, so just use a `.' as a placeholder for now. */ 619 fprintf (aux_info_file, "/* compiled from: . */\n"); 620 } 621 622 /* Write the actual line of auxiliary info. */ 623 624 fprintf (aux_info_file, "/* %s:%d:%c%c */ %s;", 625 DECL_SOURCE_FILE (fndecl), 626 DECL_SOURCE_LINE (fndecl), 627 (is_implicit) ? 'I' : (is_prototyped) ? 'N' : 'O', 628 (is_definition) ? 'F' : 'C', 629 gen_decl (fndecl, is_definition, ansi)); 630 631 /* If this is an explicit function declaration, we need to also write 632 out an old-style (i.e. K&R) function header, just in case the user 633 wants to run unprotoize. */ 634 635 if (is_definition) 636 { 637 fprintf (aux_info_file, " /*%s %s*/", 638 gen_formal_list_for_func_def (fndecl, k_and_r_names), 639 gen_formal_list_for_func_def (fndecl, k_and_r_decls)); 640 } 641 642 fprintf (aux_info_file, "\n"); 643 } 644} 645