1 /* Definitions for symbol file management in GDB. 2 Copyright (C) 1992, 1993, 1994, 1995 Free Software Foundation, Inc. 3 4 This file is part of GDB. 5 6 This program is free software; you can redistribute it and/or modify 7 it under the terms of the GNU General Public License as published by 8 the Free Software Foundation; either version 2 of the License, or 9 (at your option) any later version. 10 11 This program is distributed in the hope that it will be useful, 12 but WITHOUT ANY WARRANTY; without even the implied warranty of 13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 14 GNU General Public License for more details. 15 16 You should have received a copy of the GNU General Public License 17 along with this program; if not, write to the Free Software 18 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ 19 20 #if !defined (OBJFILES_H) 21 #define OBJFILES_H 22 23 /* This structure maintains information on a per-objfile basis about the 24 "entry point" of the objfile, and the scope within which the entry point 25 exists. It is possible that gdb will see more than one objfile that is 26 executable, each with its own entry point. 27 28 For example, for dynamically linked executables in SVR4, the dynamic linker 29 code is contained within the shared C library, which is actually executable 30 and is run by the kernel first when an exec is done of a user executable 31 that is dynamically linked. The dynamic linker within the shared C library 32 then maps in the various program segments in the user executable and jumps 33 to the user executable's recorded entry point, as if the call had been made 34 directly by the kernel. 35 36 The traditional gdb method of using this info is to use the recorded entry 37 point to set the variables entry_file_lowpc and entry_file_highpc from 38 the debugging information, where these values are the starting address 39 (inclusive) and ending address (exclusive) of the instruction space in the 40 executable which correspond to the "startup file", I.E. crt0.o in most 41 cases. This file is assumed to be a startup file and frames with pc's 42 inside it are treated as nonexistent. Setting these variables is necessary 43 so that backtraces do not fly off the bottom of the stack. 44 45 Gdb also supports an alternate method to avoid running off the bottom 46 of the stack. 47 48 There are two frames that are "special", the frame for the function 49 containing the process entry point, since it has no predecessor frame, 50 and the frame for the function containing the user code entry point 51 (the main() function), since all the predecessor frames are for the 52 process startup code. Since we have no guarantee that the linked 53 in startup modules have any debugging information that gdb can use, 54 we need to avoid following frame pointers back into frames that might 55 have been built in the startup code, as we might get hopelessly 56 confused. However, we almost always have debugging information 57 available for main(). 58 59 These variables are used to save the range of PC values which are valid 60 within the main() function and within the function containing the process 61 entry point. If we always consider the frame for main() as the outermost 62 frame when debugging user code, and the frame for the process entry 63 point function as the outermost frame when debugging startup code, then 64 all we have to do is have FRAME_CHAIN_VALID return false whenever a 65 frame's current PC is within the range specified by these variables. 66 In essence, we set "ceilings" in the frame chain beyond which we will 67 not proceed when following the frame chain back up the stack. 68 69 A nice side effect is that we can still debug startup code without 70 running off the end of the frame chain, assuming that we have usable 71 debugging information in the startup modules, and if we choose to not 72 use the block at main, or can't find it for some reason, everything 73 still works as before. And if we have no startup code debugging 74 information but we do have usable information for main(), backtraces 75 from user code don't go wandering off into the startup code. 76 77 To use this method, define your FRAME_CHAIN_VALID macro like: 78 79 #define FRAME_CHAIN_VALID(chain, thisframe) \ 80 (chain != 0 \ 81 && !(inside_main_func ((thisframe)->pc)) \ 82 && !(inside_entry_func ((thisframe)->pc))) 83 84 and add initializations of the four scope controlling variables inside 85 the object file / debugging information processing modules. */ 86 87 struct entry_info 88 { 89 90 /* The value we should use for this objects entry point. 91 The illegal/unknown value needs to be something other than 0, ~0 92 for instance, which is much less likely than 0. */ 93 94 CORE_ADDR entry_point; 95 96 #define INVALID_ENTRY_POINT (~0) /* ~0 will not be in any file, we hope. */ 97 98 /* Start (inclusive) and end (exclusive) of function containing the 99 entry point. */ 100 101 CORE_ADDR entry_func_lowpc; 102 CORE_ADDR entry_func_highpc; 103 104 /* Start (inclusive) and end (exclusive) of object file containing the 105 entry point. */ 106 107 CORE_ADDR entry_file_lowpc; 108 CORE_ADDR entry_file_highpc; 109 110 /* Start (inclusive) and end (exclusive) of the user code main() function. */ 111 112 CORE_ADDR main_func_lowpc; 113 CORE_ADDR main_func_highpc; 114 115 /* Use these values when any of the above ranges is invalid. */ 116 117 /* We use these values because it guarantees that there is no number that is 118 both >= LOWPC && < HIGHPC. It is also highly unlikely that 3 is a valid 119 module or function start address (as opposed to 0). */ 120 121 #define INVALID_ENTRY_LOWPC (3) 122 #define INVALID_ENTRY_HIGHPC (1) 123 124 }; 125 126 /* Sections in an objfile. 127 128 It is strange that we have both this notion of "sections" 129 and the one used by section_offsets. Section as used 130 here, (currently at least) means a BFD section, and the sections 131 are set up from the BFD sections in allocate_objfile. 132 133 The sections in section_offsets have their meaning determined by 134 the symbol format, and they are set up by the sym_offsets function 135 for that symbol file format. 136 137 I'm not sure this could or should be changed, however. */ 138 139 struct obj_section { 140 CORE_ADDR addr; /* lowest address in section */ 141 CORE_ADDR endaddr; /* 1+highest address in section */ 142 143 /* This field is being used for nefarious purposes by syms_from_objfile. 144 It is said to be redundant with section_offsets; it's not really being 145 used that way, however, it's some sort of hack I don't understand 146 and am not going to try to eliminate (yet, anyway). FIXME. 147 148 It was documented as "offset between (end)addr and actual memory 149 addresses", but that's not true; addr & endaddr are actual memory 150 addresses. */ 151 CORE_ADDR offset; 152 153 sec_ptr the_bfd_section; /* BFD section pointer */ 154 155 /* Objfile this section is part of. */ 156 struct objfile *objfile; 157 }; 158 159 /* The "objstats" structure provides a place for gdb to record some 160 interesting information about its internal state at runtime, on a 161 per objfile basis, such as information about the number of symbols 162 read, size of string table (if any), etc. */ 163 164 #if MAINTENANCE_CMDS 165 166 struct objstats { 167 int n_minsyms; /* Number of minimal symbols read */ 168 int n_psyms; /* Number of partial symbols read */ 169 int n_syms; /* Number of full symbols read */ 170 int n_stabs; /* Number of ".stabs" read (if applicable) */ 171 int n_types; /* Number of types */ 172 int sz_strtab; /* Size of stringtable, (if applicable) */ 173 }; 174 175 #define OBJSTAT(objfile, expr) (objfile -> stats.expr) 176 #define OBJSTATS struct objstats stats 177 extern void print_objfile_statistics PARAMS ((void)); 178 extern void print_symbol_bcache_statistics PARAMS ((void)); 179 180 #else 181 182 #define OBJSTAT(objfile, expr) /* Nothing */ 183 #define OBJSTATS /* Nothing */ 184 185 #endif /* MAINTENANCE_CMDS */ 186 187 /* Master structure for keeping track of each file from which 188 gdb reads symbols. There are several ways these get allocated: 1. 189 The main symbol file, symfile_objfile, set by the symbol-file command, 190 2. Additional symbol files added by the add-symbol-file command, 191 3. Shared library objfiles, added by ADD_SOLIB, 4. symbol files 192 for modules that were loaded when GDB attached to a remote system 193 (see remote-vx.c). */ 194 195 struct objfile 196 { 197 198 /* All struct objfile's are chained together by their next pointers. 199 The global variable "object_files" points to the first link in this 200 chain. 201 202 FIXME: There is a problem here if the objfile is reusable, and if 203 multiple users are to be supported. The problem is that the objfile 204 list is linked through a member of the objfile struct itself, which 205 is only valid for one gdb process. The list implementation needs to 206 be changed to something like: 207 208 struct list {struct list *next; struct objfile *objfile}; 209 210 where the list structure is completely maintained separately within 211 each gdb process. */ 212 213 struct objfile *next; 214 215 /* The object file's name. Malloc'd; free it if you free this struct. */ 216 217 char *name; 218 219 /* Some flag bits for this objfile. */ 220 221 unsigned short flags; 222 223 /* Each objfile points to a linked list of symtabs derived from this file, 224 one symtab structure for each compilation unit (source file). Each link 225 in the symtab list contains a backpointer to this objfile. */ 226 227 struct symtab *symtabs; 228 229 /* Each objfile points to a linked list of partial symtabs derived from 230 this file, one partial symtab structure for each compilation unit 231 (source file). */ 232 233 struct partial_symtab *psymtabs; 234 235 /* List of freed partial symtabs, available for re-use */ 236 237 struct partial_symtab *free_psymtabs; 238 239 /* The object file's BFD. Can be null if the objfile contains only 240 minimal symbols, e.g. the run time common symbols for SunOS4. */ 241 242 bfd *obfd; 243 244 /* The modification timestamp of the object file, as of the last time 245 we read its symbols. */ 246 247 long mtime; 248 249 /* Obstacks to hold objects that should be freed when we load a new symbol 250 table from this object file. */ 251 252 struct obstack psymbol_obstack; /* Partial symbols */ 253 struct obstack symbol_obstack; /* Full symbols */ 254 struct obstack type_obstack; /* Types */ 255 256 /* A byte cache where we can stash arbitrary "chunks" of bytes that 257 will not change. */ 258 259 struct bcache psymbol_cache; /* Byte cache for partial syms */ 260 261 /* Vectors of all partial symbols read in from file. The actual data 262 is stored in the psymbol_obstack. */ 263 264 struct psymbol_allocation_list global_psymbols; 265 struct psymbol_allocation_list static_psymbols; 266 267 /* Each file contains a pointer to an array of minimal symbols for all 268 global symbols that are defined within the file. The array is terminated 269 by a "null symbol", one that has a NULL pointer for the name and a zero 270 value for the address. This makes it easy to walk through the array 271 when passed a pointer to somewhere in the middle of it. There is also 272 a count of the number of symbols, which does not include the terminating 273 null symbol. The array itself, as well as all the data that it points 274 to, should be allocated on the symbol_obstack for this file. */ 275 276 struct minimal_symbol *msymbols; 277 int minimal_symbol_count; 278 279 /* For object file formats which don't specify fundamental types, gdb 280 can create such types. For now, it maintains a vector of pointers 281 to these internally created fundamental types on a per objfile basis, 282 however it really should ultimately keep them on a per-compilation-unit 283 basis, to account for linkage-units that consist of a number of 284 compilation units that may have different fundamental types, such as 285 linking C modules with ADA modules, or linking C modules that are 286 compiled with 32-bit ints with C modules that are compiled with 64-bit 287 ints (not inherently evil with a smarter linker). */ 288 289 struct type **fundamental_types; 290 291 /* The mmalloc() malloc-descriptor for this objfile if we are using 292 the memory mapped malloc() package to manage storage for this objfile's 293 data. NULL if we are not. */ 294 295 PTR md; 296 297 /* The file descriptor that was used to obtain the mmalloc descriptor 298 for this objfile. If we call mmalloc_detach with the malloc descriptor 299 we should then close this file descriptor. */ 300 301 int mmfd; 302 303 /* Structure which keeps track of functions that manipulate objfile's 304 of the same type as this objfile. I.E. the function to read partial 305 symbols for example. Note that this structure is in statically 306 allocated memory, and is shared by all objfiles that use the 307 object module reader of this type. */ 308 309 struct sym_fns *sf; 310 311 /* The per-objfile information about the entry point, the scope (file/func) 312 containing the entry point, and the scope of the user's main() func. */ 313 314 struct entry_info ei; 315 316 /* Information about stabs. Will be filled in with a dbx_symfile_info 317 struct by those readers that need it. */ 318 319 PTR sym_stab_info; 320 321 /* Hook for information for use by the symbol reader (currently used 322 for information shared by sym_init and sym_read). It is 323 typically a pointer to malloc'd memory. The symbol reader's finish 324 function is responsible for freeing the memory thusly allocated. */ 325 326 PTR sym_private; 327 328 /* Hook for target-architecture-specific information. This must 329 point to memory allocated on one of the obstacks in this objfile, 330 so that it gets freed automatically when reading a new object 331 file. */ 332 333 PTR obj_private; 334 335 /* Set of relocation offsets to apply to each section. 336 Currently on the psymbol_obstack (which makes no sense, but I'm 337 not sure it's harming anything). 338 339 These offsets indicate that all symbols (including partial and 340 minimal symbols) which have been read have been relocated by this 341 much. Symbols which are yet to be read need to be relocated by 342 it. */ 343 344 struct section_offsets *section_offsets; 345 int num_sections; 346 347 /* set of section begin and end addresses used to map pc addresses 348 into sections. Currently on the psymbol_obstack (which makes no 349 sense, but I'm not sure it's harming anything). */ 350 351 struct obj_section 352 *sections, 353 *sections_end; 354 355 /* two auxiliary fields, used to hold the fp of separate symbol files */ 356 FILE *auxf1, *auxf2; 357 358 /* Place to stash various statistics about this objfile */ 359 OBJSTATS; 360 }; 361 362 /* Defines for the objfile flag word. */ 363 364 /* Gdb can arrange to allocate storage for all objects related to a 365 particular objfile in a designated section of its address space, 366 managed at a low level by mmap() and using a special version of 367 malloc that handles malloc/free/realloc on top of the mmap() interface. 368 This allows the "internal gdb state" for a particular objfile to be 369 dumped to a gdb state file and subsequently reloaded at a later time. */ 370 371 #define OBJF_MAPPED (1 << 0) /* Objfile data is mmap'd */ 372 373 /* When using mapped/remapped predigested gdb symbol information, we need 374 a flag that indicates that we have previously done an initial symbol 375 table read from this particular objfile. We can't just look for the 376 absence of any of the three symbol tables (msymbols, psymtab, symtab) 377 because if the file has no symbols for example, none of these will 378 exist. */ 379 380 #define OBJF_SYMS (1 << 1) /* Have tried to read symbols */ 381 382 /* When an object file has its functions reordered (currently Irix-5.2 383 shared libraries exhibit this behaviour), we will need an expensive 384 algorithm to locate a partial symtab or symtab via an address. 385 To avoid this penalty for normal object files, we use this flag, 386 whose setting is determined upon symbol table read in. */ 387 388 #define OBJF_REORDERED (2 << 1) /* Functions are reordered */ 389 390 /* The object file that the main symbol table was loaded from (e.g. the 391 argument to the "symbol-file" or "file" command). */ 392 393 extern struct objfile *symfile_objfile; 394 395 /* The object file that contains the runtime common minimal symbols 396 for SunOS4. Note that this objfile has no associated BFD. */ 397 398 extern struct objfile *rt_common_objfile; 399 400 /* When we need to allocate a new type, we need to know which type_obstack 401 to allocate the type on, since there is one for each objfile. The places 402 where types are allocated are deeply buried in function call hierarchies 403 which know nothing about objfiles, so rather than trying to pass a 404 particular objfile down to them, we just do an end run around them and 405 set current_objfile to be whatever objfile we expect to be using at the 406 time types are being allocated. For instance, when we start reading 407 symbols for a particular objfile, we set current_objfile to point to that 408 objfile, and when we are done, we set it back to NULL, to ensure that we 409 never put a type someplace other than where we are expecting to put it. 410 FIXME: Maybe we should review the entire type handling system and 411 see if there is a better way to avoid this problem. */ 412 413 extern struct objfile *current_objfile; 414 415 /* All known objfiles are kept in a linked list. This points to the 416 root of this list. */ 417 418 extern struct objfile *object_files; 419 420 /* Declarations for functions defined in objfiles.c */ 421 422 extern struct objfile * 423 allocate_objfile PARAMS ((bfd *, int)); 424 425 extern int 426 build_objfile_section_table PARAMS ((struct objfile *)); 427 428 extern void objfile_to_front PARAMS ((struct objfile *)); 429 430 extern void 431 unlink_objfile PARAMS ((struct objfile *)); 432 433 extern void 434 free_objfile PARAMS ((struct objfile *)); 435 436 extern void 437 free_all_objfiles PARAMS ((void)); 438 439 extern void 440 objfile_relocate PARAMS ((struct objfile *, struct section_offsets *)); 441 442 extern int 443 have_partial_symbols PARAMS ((void)); 444 445 extern int 446 have_full_symbols PARAMS ((void)); 447 448 /* Functions for dealing with the minimal symbol table, really a misc 449 address<->symbol mapping for things we don't have debug symbols for. */ 450 451 extern int 452 have_minimal_symbols PARAMS ((void)); 453 454 extern struct obj_section * 455 find_pc_section PARAMS((CORE_ADDR pc)); 456 457 extern int 458 in_plt_section PARAMS ((CORE_ADDR, char *)); 459 460 /* Traverse all object files. ALL_OBJFILES_SAFE works even if you delete 461 the objfile during the traversal. */ 462 463 #define ALL_OBJFILES(obj) \ 464 for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next) 465 466 #define ALL_OBJFILES_SAFE(obj,nxt) \ 467 for ((obj) = object_files; \ 468 (obj) != NULL? ((nxt)=(obj)->next,1) :0; \ 469 (obj) = (nxt)) 470 471 /* Traverse all symtabs in one objfile. */ 472 473 #define ALL_OBJFILE_SYMTABS(objfile, s) \ 474 for ((s) = (objfile) -> symtabs; (s) != NULL; (s) = (s) -> next) 475 476 /* Traverse all psymtabs in one objfile. */ 477 478 #define ALL_OBJFILE_PSYMTABS(objfile, p) \ 479 for ((p) = (objfile) -> psymtabs; (p) != NULL; (p) = (p) -> next) 480 481 /* Traverse all minimal symbols in one objfile. */ 482 483 #define ALL_OBJFILE_MSYMBOLS(objfile, m) \ 484 for ((m) = (objfile) -> msymbols; SYMBOL_NAME(m) != NULL; (m)++) 485 486 /* Traverse all symtabs in all objfiles. */ 487 488 #define ALL_SYMTABS(objfile, s) \ 489 ALL_OBJFILES (objfile) \ 490 ALL_OBJFILE_SYMTABS (objfile, s) 491 492 /* Traverse all psymtabs in all objfiles. */ 493 494 #define ALL_PSYMTABS(objfile, p) \ 495 ALL_OBJFILES (objfile) \ 496 ALL_OBJFILE_PSYMTABS (objfile, p) 497 498 /* Traverse all minimal symbols in all objfiles. */ 499 500 #define ALL_MSYMBOLS(objfile, m) \ 501 ALL_OBJFILES (objfile) \ 502 if ((objfile)->msymbols) \ 503 ALL_OBJFILE_MSYMBOLS (objfile, m) 504 505 #endif /* !defined (OBJFILES_H) */ 506