1/* Definitions for symbol file management in GDB. 2 3 Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 4 2002, 2003, 2004, 2007 Free Software Foundation, Inc. 5 6 This file is part of GDB. 7 8 This program is free software; you can redistribute it and/or modify 9 it under the terms of the GNU General Public License as published by 10 the Free Software Foundation; either version 3 of the License, or 11 (at your option) any later version. 12 13 This program is distributed in the hope that it will be useful, 14 but WITHOUT ANY WARRANTY; without even the implied warranty of 15 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 16 GNU General Public License for more details. 17 18 You should have received a copy of the GNU General Public License 19 along with this program. If not, see <http://www.gnu.org/licenses/>. */ 20 21#if !defined (OBJFILES_H) 22#define OBJFILES_H 23 24#include "gdb_obstack.h" /* For obstack internals. */ 25#include "symfile.h" /* For struct psymbol_allocation_list */ 26 27struct bcache; 28struct htab; 29struct symtab; 30struct objfile_data; 31 32/* This structure maintains information on a per-objfile basis about the 33 "entry point" of the objfile, and the scope within which the entry point 34 exists. It is possible that gdb will see more than one objfile that is 35 executable, each with its own entry point. 36 37 For example, for dynamically linked executables in SVR4, the dynamic linker 38 code is contained within the shared C library, which is actually executable 39 and is run by the kernel first when an exec is done of a user executable 40 that is dynamically linked. The dynamic linker within the shared C library 41 then maps in the various program segments in the user executable and jumps 42 to the user executable's recorded entry point, as if the call had been made 43 directly by the kernel. 44 45 The traditional gdb method of using this info was to use the 46 recorded entry point to set the entry-file's lowpc and highpc from 47 the debugging information, where these values are the starting 48 address (inclusive) and ending address (exclusive) of the 49 instruction space in the executable which correspond to the 50 "startup file", I.E. crt0.o in most cases. This file is assumed to 51 be a startup file and frames with pc's inside it are treated as 52 nonexistent. Setting these variables is necessary so that 53 backtraces do not fly off the bottom of the stack. 54 55 NOTE: cagney/2003-09-09: It turns out that this "traditional" 56 method doesn't work. Corinna writes: ``It turns out that the call 57 to test for "inside entry file" destroys a meaningful backtrace 58 under some conditions. E. g. the backtrace tests in the asm-source 59 testcase are broken for some targets. In this test the functions 60 are all implemented as part of one file and the testcase is not 61 necessarily linked with a start file (depending on the target). 62 What happens is, that the first frame is printed normaly and 63 following frames are treated as being inside the enttry file then. 64 This way, only the #0 frame is printed in the backtrace output.'' 65 Ref "frame.c" "NOTE: vinschen/2003-04-01". 66 67 Gdb also supports an alternate method to avoid running off the bottom 68 of the stack. 69 70 There are two frames that are "special", the frame for the function 71 containing the process entry point, since it has no predecessor frame, 72 and the frame for the function containing the user code entry point 73 (the main() function), since all the predecessor frames are for the 74 process startup code. Since we have no guarantee that the linked 75 in startup modules have any debugging information that gdb can use, 76 we need to avoid following frame pointers back into frames that might 77 have been built in the startup code, as we might get hopelessly 78 confused. However, we almost always have debugging information 79 available for main(). 80 81 These variables are used to save the range of PC values which are 82 valid within the main() function and within the function containing 83 the process entry point. If we always consider the frame for 84 main() as the outermost frame when debugging user code, and the 85 frame for the process entry point function as the outermost frame 86 when debugging startup code, then all we have to do is have 87 DEPRECATED_FRAME_CHAIN_VALID return false whenever a frame's 88 current PC is within the range specified by these variables. In 89 essence, we set "ceilings" in the frame chain beyond which we will 90 not proceed when following the frame chain back up the stack. 91 92 A nice side effect is that we can still debug startup code without 93 running off the end of the frame chain, assuming that we have usable 94 debugging information in the startup modules, and if we choose to not 95 use the block at main, or can't find it for some reason, everything 96 still works as before. And if we have no startup code debugging 97 information but we do have usable information for main(), backtraces 98 from user code don't go wandering off into the startup code. */ 99 100struct entry_info 101 { 102 103 /* The value we should use for this objects entry point. 104 The illegal/unknown value needs to be something other than 0, ~0 105 for instance, which is much less likely than 0. */ 106 107 CORE_ADDR entry_point; 108 109#define INVALID_ENTRY_POINT (~0) /* ~0 will not be in any file, we hope. */ 110 111 }; 112 113/* Sections in an objfile. 114 115 It is strange that we have both this notion of "sections" 116 and the one used by section_offsets. Section as used 117 here, (currently at least) means a BFD section, and the sections 118 are set up from the BFD sections in allocate_objfile. 119 120 The sections in section_offsets have their meaning determined by 121 the symbol format, and they are set up by the sym_offsets function 122 for that symbol file format. 123 124 I'm not sure this could or should be changed, however. */ 125 126struct obj_section 127 { 128 CORE_ADDR addr; /* lowest address in section */ 129 CORE_ADDR endaddr; /* 1+highest address in section */ 130 131 /* This field is being used for nefarious purposes by syms_from_objfile. 132 It is said to be redundant with section_offsets; it's not really being 133 used that way, however, it's some sort of hack I don't understand 134 and am not going to try to eliminate (yet, anyway). FIXME. 135 136 It was documented as "offset between (end)addr and actual memory 137 addresses", but that's not true; addr & endaddr are actual memory 138 addresses. */ 139 CORE_ADDR offset; 140 141 struct bfd_section *the_bfd_section; /* BFD section pointer */ 142 143 /* Objfile this section is part of. */ 144 struct objfile *objfile; 145 146 /* True if this "overlay section" is mapped into an "overlay region". */ 147 int ovly_mapped; 148 }; 149 150 151/* The "objstats" structure provides a place for gdb to record some 152 interesting information about its internal state at runtime, on a 153 per objfile basis, such as information about the number of symbols 154 read, size of string table (if any), etc. */ 155 156struct objstats 157 { 158 int n_minsyms; /* Number of minimal symbols read */ 159 int n_psyms; /* Number of partial symbols read */ 160 int n_syms; /* Number of full symbols read */ 161 int n_stabs; /* Number of ".stabs" read (if applicable) */ 162 int n_types; /* Number of types */ 163 int sz_strtab; /* Size of stringtable, (if applicable) */ 164 }; 165 166#define OBJSTAT(objfile, expr) (objfile -> stats.expr) 167#define OBJSTATS struct objstats stats 168extern void print_objfile_statistics (void); 169extern void print_symbol_bcache_statistics (void); 170 171/* Number of entries in the minimal symbol hash table. */ 172#define MINIMAL_SYMBOL_HASH_SIZE 2039 173 174/* Master structure for keeping track of each file from which 175 gdb reads symbols. There are several ways these get allocated: 1. 176 The main symbol file, symfile_objfile, set by the symbol-file command, 177 2. Additional symbol files added by the add-symbol-file command, 178 3. Shared library objfiles, added by ADD_SOLIB, 4. symbol files 179 for modules that were loaded when GDB attached to a remote system 180 (see remote-vx.c). */ 181 182struct objfile 183 { 184 185 /* All struct objfile's are chained together by their next pointers. 186 The global variable "object_files" points to the first link in this 187 chain. 188 189 FIXME: There is a problem here if the objfile is reusable, and if 190 multiple users are to be supported. The problem is that the objfile 191 list is linked through a member of the objfile struct itself, which 192 is only valid for one gdb process. The list implementation needs to 193 be changed to something like: 194 195 struct list {struct list *next; struct objfile *objfile}; 196 197 where the list structure is completely maintained separately within 198 each gdb process. */ 199 200 struct objfile *next; 201 202 /* The object file's name, tilde-expanded and absolute. 203 Malloc'd; free it if you free this struct. */ 204 205 char *name; 206 207 /* Some flag bits for this objfile. */ 208 209 unsigned short flags; 210 211 /* Each objfile points to a linked list of symtabs derived from this file, 212 one symtab structure for each compilation unit (source file). Each link 213 in the symtab list contains a backpointer to this objfile. */ 214 215 struct symtab *symtabs; 216 217 /* Each objfile points to a linked list of partial symtabs derived from 218 this file, one partial symtab structure for each compilation unit 219 (source file). */ 220 221 struct partial_symtab *psymtabs; 222 223 /* List of freed partial symtabs, available for re-use */ 224 225 struct partial_symtab *free_psymtabs; 226 227 /* The object file's BFD. Can be null if the objfile contains only 228 minimal symbols, e.g. the run time common symbols for SunOS4. */ 229 230 bfd *obfd; 231 232 /* The modification timestamp of the object file, as of the last time 233 we read its symbols. */ 234 235 long mtime; 236 237 /* Obstack to hold objects that should be freed when we load a new symbol 238 table from this object file. */ 239 240 struct obstack objfile_obstack; 241 242 /* A byte cache where we can stash arbitrary "chunks" of bytes that 243 will not change. */ 244 245 struct bcache *psymbol_cache; /* Byte cache for partial syms */ 246 struct bcache *macro_cache; /* Byte cache for macros */ 247 248 /* Hash table for mapping symbol names to demangled names. Each 249 entry in the hash table is actually two consecutive strings, 250 both null-terminated; the first one is a mangled or linkage 251 name, and the second is the demangled name or just a zero byte 252 if the name doesn't demangle. */ 253 struct htab *demangled_names_hash; 254 255 /* Vectors of all partial symbols read in from file. The actual data 256 is stored in the objfile_obstack. */ 257 258 struct psymbol_allocation_list global_psymbols; 259 struct psymbol_allocation_list static_psymbols; 260 261 /* Each file contains a pointer to an array of minimal symbols for all 262 global symbols that are defined within the file. The array is terminated 263 by a "null symbol", one that has a NULL pointer for the name and a zero 264 value for the address. This makes it easy to walk through the array 265 when passed a pointer to somewhere in the middle of it. There is also 266 a count of the number of symbols, which does not include the terminating 267 null symbol. The array itself, as well as all the data that it points 268 to, should be allocated on the objfile_obstack for this file. */ 269 270 struct minimal_symbol *msymbols; 271 int minimal_symbol_count; 272 273 /* This is a hash table used to index the minimal symbols by name. */ 274 275 struct minimal_symbol *msymbol_hash[MINIMAL_SYMBOL_HASH_SIZE]; 276 277 /* This hash table is used to index the minimal symbols by their 278 demangled names. */ 279 280 struct minimal_symbol *msymbol_demangled_hash[MINIMAL_SYMBOL_HASH_SIZE]; 281 282 /* For object file formats which don't specify fundamental types, gdb 283 can create such types. For now, it maintains a vector of pointers 284 to these internally created fundamental types on a per objfile basis, 285 however it really should ultimately keep them on a per-compilation-unit 286 basis, to account for linkage-units that consist of a number of 287 compilation units that may have different fundamental types, such as 288 linking C modules with ADA modules, or linking C modules that are 289 compiled with 32-bit ints with C modules that are compiled with 64-bit 290 ints (not inherently evil with a smarter linker). */ 291 292 struct type **fundamental_types; 293 294 /* The mmalloc() malloc-descriptor for this objfile if we are using 295 the memory mapped malloc() package to manage storage for this objfile's 296 data. NULL if we are not. */ 297 298 void *md; 299 300 /* The file descriptor that was used to obtain the mmalloc descriptor 301 for this objfile. If we call mmalloc_detach with the malloc descriptor 302 we should then close this file descriptor. */ 303 304 int mmfd; 305 306 /* Structure which keeps track of functions that manipulate objfile's 307 of the same type as this objfile. I.E. the function to read partial 308 symbols for example. Note that this structure is in statically 309 allocated memory, and is shared by all objfiles that use the 310 object module reader of this type. */ 311 312 struct sym_fns *sf; 313 314 /* The per-objfile information about the entry point, the scope (file/func) 315 containing the entry point, and the scope of the user's main() func. */ 316 317 struct entry_info ei; 318 319 /* Information about stabs. Will be filled in with a dbx_symfile_info 320 struct by those readers that need it. */ 321 /* NOTE: cagney/2004-10-23: This has been replaced by per-objfile 322 data points implemented using "data" and "num_data" below. For 323 an example of how to use this replacement, see "objfile_data" 324 in "mips-tdep.c". */ 325 326 struct dbx_symfile_info *deprecated_sym_stab_info; 327 328 /* Hook for information for use by the symbol reader (currently used 329 for information shared by sym_init and sym_read). It is 330 typically a pointer to malloc'd memory. The symbol reader's finish 331 function is responsible for freeing the memory thusly allocated. */ 332 /* NOTE: cagney/2004-10-23: This has been replaced by per-objfile 333 data points implemented using "data" and "num_data" below. For 334 an example of how to use this replacement, see "objfile_data" 335 in "mips-tdep.c". */ 336 337 void *deprecated_sym_private; 338 339 /* Hook for target-architecture-specific information. This must 340 point to memory allocated on one of the obstacks in this objfile, 341 so that it gets freed automatically when reading a new object 342 file. */ 343 344 void *deprecated_obj_private; 345 346 /* Per objfile data-pointers required by other GDB modules. */ 347 /* FIXME: kettenis/20030711: This mechanism could replace 348 deprecated_sym_stab_info, deprecated_sym_private and 349 deprecated_obj_private entirely. */ 350 351 void **data; 352 unsigned num_data; 353 354 /* Set of relocation offsets to apply to each section. 355 Currently on the objfile_obstack (which makes no sense, but I'm 356 not sure it's harming anything). 357 358 These offsets indicate that all symbols (including partial and 359 minimal symbols) which have been read have been relocated by this 360 much. Symbols which are yet to be read need to be relocated by 361 it. */ 362 363 struct section_offsets *section_offsets; 364 int num_sections; 365 366 /* Indexes in the section_offsets array. These are initialized by the 367 *_symfile_offsets() family of functions (som_symfile_offsets, 368 xcoff_symfile_offsets, default_symfile_offsets). In theory they 369 should correspond to the section indexes used by bfd for the 370 current objfile. The exception to this for the time being is the 371 SOM version. */ 372 373 int sect_index_text; 374 int sect_index_data; 375 int sect_index_bss; 376 int sect_index_rodata; 377 378 /* These pointers are used to locate the section table, which 379 among other things, is used to map pc addresses into sections. 380 SECTIONS points to the first entry in the table, and 381 SECTIONS_END points to the first location past the last entry 382 in the table. Currently the table is stored on the 383 objfile_obstack (which makes no sense, but I'm not sure it's 384 harming anything). */ 385 386 struct obj_section 387 *sections, *sections_end; 388 389 /* Link to objfile that contains the debug symbols for this one. 390 One is loaded if this file has an debug link to an existing 391 debug file with the right checksum */ 392 struct objfile *separate_debug_objfile; 393 394 /* If this is a separate debug object, this is used as a link to the 395 actual executable objfile. */ 396 struct objfile *separate_debug_objfile_backlink; 397 398 /* Place to stash various statistics about this objfile */ 399 OBJSTATS; 400 401 /* A symtab that the C++ code uses to stash special symbols 402 associated to namespaces. */ 403 404 /* FIXME/carlton-2003-06-27: Delete this in a few years once 405 "possible namespace symbols" go away. */ 406 struct symtab *cp_namespace_symtab; 407 }; 408 409/* Defines for the objfile flag word. */ 410 411/* When using mapped/remapped predigested gdb symbol information, we need 412 a flag that indicates that we have previously done an initial symbol 413 table read from this particular objfile. We can't just look for the 414 absence of any of the three symbol tables (msymbols, psymtab, symtab) 415 because if the file has no symbols for example, none of these will 416 exist. */ 417 418#define OBJF_SYMS (1 << 1) /* Have tried to read symbols */ 419 420/* When an object file has its functions reordered (currently Irix-5.2 421 shared libraries exhibit this behaviour), we will need an expensive 422 algorithm to locate a partial symtab or symtab via an address. 423 To avoid this penalty for normal object files, we use this flag, 424 whose setting is determined upon symbol table read in. */ 425 426#define OBJF_REORDERED (1 << 2) /* Functions are reordered */ 427 428/* Distinguish between an objfile for a shared library and a "vanilla" 429 objfile. (If not set, the objfile may still actually be a solib. 430 This can happen if the user created the objfile by using the 431 add-symbol-file command. GDB doesn't in that situation actually 432 check whether the file is a solib. Rather, the target's 433 implementation of the solib interface is responsible for setting 434 this flag when noticing solibs used by an inferior.) */ 435 436#define OBJF_SHARED (1 << 3) /* From a shared library */ 437 438/* User requested that this objfile be read in it's entirety. */ 439 440#define OBJF_READNOW (1 << 4) /* Immediate full read */ 441 442/* This objfile was created because the user explicitly caused it 443 (e.g., used the add-symbol-file command). This bit offers a way 444 for run_command to remove old objfile entries which are no longer 445 valid (i.e., are associated with an old inferior), but to preserve 446 ones that the user explicitly loaded via the add-symbol-file 447 command. */ 448 449#define OBJF_USERLOADED (1 << 5) /* User loaded */ 450 451/* The object file that the main symbol table was loaded from (e.g. the 452 argument to the "symbol-file" or "file" command). */ 453 454extern struct objfile *symfile_objfile; 455 456/* The object file that contains the runtime common minimal symbols 457 for SunOS4. Note that this objfile has no associated BFD. */ 458 459extern struct objfile *rt_common_objfile; 460 461/* When we need to allocate a new type, we need to know which objfile_obstack 462 to allocate the type on, since there is one for each objfile. The places 463 where types are allocated are deeply buried in function call hierarchies 464 which know nothing about objfiles, so rather than trying to pass a 465 particular objfile down to them, we just do an end run around them and 466 set current_objfile to be whatever objfile we expect to be using at the 467 time types are being allocated. For instance, when we start reading 468 symbols for a particular objfile, we set current_objfile to point to that 469 objfile, and when we are done, we set it back to NULL, to ensure that we 470 never put a type someplace other than where we are expecting to put it. 471 FIXME: Maybe we should review the entire type handling system and 472 see if there is a better way to avoid this problem. */ 473 474extern struct objfile *current_objfile; 475 476/* All known objfiles are kept in a linked list. This points to the 477 root of this list. */ 478 479extern struct objfile *object_files; 480 481/* Declarations for functions defined in objfiles.c */ 482 483extern struct objfile *allocate_objfile (bfd *, int); 484 485extern void init_entry_point_info (struct objfile *); 486 487extern CORE_ADDR entry_point_address (void); 488 489extern int build_objfile_section_table (struct objfile *); 490 491extern void terminate_minimal_symbol_table (struct objfile *objfile); 492 493extern void put_objfile_before (struct objfile *, struct objfile *); 494 495extern void objfile_to_front (struct objfile *); 496 497extern void unlink_objfile (struct objfile *); 498 499extern void free_objfile (struct objfile *); 500 501extern struct cleanup *make_cleanup_free_objfile (struct objfile *); 502 503extern void free_all_objfiles (void); 504 505extern void objfile_relocate (struct objfile *, struct section_offsets *); 506 507extern int have_partial_symbols (void); 508 509extern int have_full_symbols (void); 510 511/* This operation deletes all objfile entries that represent solibs that 512 weren't explicitly loaded by the user, via e.g., the add-symbol-file 513 command. 514 */ 515extern void objfile_purge_solibs (void); 516 517/* Functions for dealing with the minimal symbol table, really a misc 518 address<->symbol mapping for things we don't have debug symbols for. */ 519 520extern int have_minimal_symbols (void); 521 522extern struct obj_section *find_pc_section (CORE_ADDR pc); 523 524extern struct obj_section *find_pc_sect_section (CORE_ADDR pc, 525 asection * section); 526 527extern int in_plt_section (CORE_ADDR, char *); 528 529/* Keep a registry of per-objfile data-pointers required by other GDB 530 modules. */ 531 532extern const struct objfile_data *register_objfile_data (void); 533extern void clear_objfile_data (struct objfile *objfile); 534extern void set_objfile_data (struct objfile *objfile, 535 const struct objfile_data *data, void *value); 536extern void *objfile_data (struct objfile *objfile, 537 const struct objfile_data *data); 538 539 540/* Traverse all object files. ALL_OBJFILES_SAFE works even if you delete 541 the objfile during the traversal. */ 542 543#define ALL_OBJFILES(obj) \ 544 for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next) 545 546#define ALL_OBJFILES_SAFE(obj,nxt) \ 547 for ((obj) = object_files; \ 548 (obj) != NULL? ((nxt)=(obj)->next,1) :0; \ 549 (obj) = (nxt)) 550 551/* Traverse all symtabs in one objfile. */ 552 553#define ALL_OBJFILE_SYMTABS(objfile, s) \ 554 for ((s) = (objfile) -> symtabs; (s) != NULL; (s) = (s) -> next) 555 556/* Traverse all psymtabs in one objfile. */ 557 558#define ALL_OBJFILE_PSYMTABS(objfile, p) \ 559 for ((p) = (objfile) -> psymtabs; (p) != NULL; (p) = (p) -> next) 560 561/* Traverse all minimal symbols in one objfile. */ 562 563#define ALL_OBJFILE_MSYMBOLS(objfile, m) \ 564 for ((m) = (objfile) -> msymbols; DEPRECATED_SYMBOL_NAME(m) != NULL; (m)++) 565 566/* Traverse all symtabs in all objfiles. */ 567 568#define ALL_SYMTABS(objfile, s) \ 569 ALL_OBJFILES (objfile) \ 570 ALL_OBJFILE_SYMTABS (objfile, s) 571 572/* Traverse all symtabs in all objfiles, skipping included files 573 (which share a blockvector with their primary symtab). */ 574 575#define ALL_PRIMARY_SYMTABS(objfile, s) \ 576 ALL_OBJFILES (objfile) \ 577 ALL_OBJFILE_SYMTABS (objfile, s) \ 578 if ((s)->primary) 579 580/* Traverse all psymtabs in all objfiles. */ 581 582#define ALL_PSYMTABS(objfile, p) \ 583 ALL_OBJFILES (objfile) \ 584 ALL_OBJFILE_PSYMTABS (objfile, p) 585 586/* Traverse all minimal symbols in all objfiles. */ 587 588#define ALL_MSYMBOLS(objfile, m) \ 589 ALL_OBJFILES (objfile) \ 590 ALL_OBJFILE_MSYMBOLS (objfile, m) 591 592#define ALL_OBJFILE_OSECTIONS(objfile, osect) \ 593 for (osect = objfile->sections; osect < objfile->sections_end; osect++) 594 595#define ALL_OBJSECTIONS(objfile, osect) \ 596 ALL_OBJFILES (objfile) \ 597 ALL_OBJFILE_OSECTIONS (objfile, osect) 598 599#define SECT_OFF_DATA(objfile) \ 600 ((objfile->sect_index_data == -1) \ 601 ? (internal_error (__FILE__, __LINE__, _("sect_index_data not initialized")), -1) \ 602 : objfile->sect_index_data) 603 604#define SECT_OFF_RODATA(objfile) \ 605 ((objfile->sect_index_rodata == -1) \ 606 ? (internal_error (__FILE__, __LINE__, _("sect_index_rodata not initialized")), -1) \ 607 : objfile->sect_index_rodata) 608 609#define SECT_OFF_TEXT(objfile) \ 610 ((objfile->sect_index_text == -1) \ 611 ? (internal_error (__FILE__, __LINE__, _("sect_index_text not initialized")), -1) \ 612 : objfile->sect_index_text) 613 614/* Sometimes the .bss section is missing from the objfile, so we don't 615 want to die here. Let the users of SECT_OFF_BSS deal with an 616 uninitialized section index. */ 617#define SECT_OFF_BSS(objfile) (objfile)->sect_index_bss 618 619#endif /* !defined (OBJFILES_H) */ 620