diff options
Diffstat (limited to 'gdb/objfiles.h')
| -rw-r--r-- | gdb/objfiles.h | 572 |
1 files changed, 572 insertions, 0 deletions
diff --git a/gdb/objfiles.h b/gdb/objfiles.h new file mode 100644 index 0000000..2a5df06 --- /dev/null +++ b/gdb/objfiles.h @@ -0,0 +1,572 @@ +/* Definitions for symbol file management in GDB. + Copyright (C) 1992, 1993, 1994, 1995 Free Software Foundation, Inc. + +This file is part of GDB. + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ + +#if !defined (OBJFILES_H) +#define OBJFILES_H + +/* This structure maintains information on a per-objfile basis about the + "entry point" of the objfile, and the scope within which the entry point + exists. It is possible that gdb will see more than one objfile that is + executable, each with its own entry point. + + For example, for dynamically linked executables in SVR4, the dynamic linker + code is contained within the shared C library, which is actually executable + and is run by the kernel first when an exec is done of a user executable + that is dynamically linked. The dynamic linker within the shared C library + then maps in the various program segments in the user executable and jumps + to the user executable's recorded entry point, as if the call had been made + directly by the kernel. + + The traditional gdb method of using this info is to use the recorded entry + point to set the variables entry_file_lowpc and entry_file_highpc from + the debugging information, where these values are the starting address + (inclusive) and ending address (exclusive) of the instruction space in the + executable which correspond to the "startup file", I.E. crt0.o in most + cases. This file is assumed to be a startup file and frames with pc's + inside it are treated as nonexistent. Setting these variables is necessary + so that backtraces do not fly off the bottom of the stack. + + Gdb also supports an alternate method to avoid running off the bottom + of the stack. + + There are two frames that are "special", the frame for the function + containing the process entry point, since it has no predecessor frame, + and the frame for the function containing the user code entry point + (the main() function), since all the predecessor frames are for the + process startup code. Since we have no guarantee that the linked + in startup modules have any debugging information that gdb can use, + we need to avoid following frame pointers back into frames that might + have been built in the startup code, as we might get hopelessly + confused. However, we almost always have debugging information + available for main(). + + These variables are used to save the range of PC values which are valid + within the main() function and within the function containing the process + entry point. If we always consider the frame for main() as the outermost + frame when debugging user code, and the frame for the process entry + point function as the outermost frame when debugging startup code, then + all we have to do is have FRAME_CHAIN_VALID return false whenever a + frame's current PC is within the range specified by these variables. + In essence, we set "ceilings" in the frame chain beyond which we will + not proceed when following the frame chain back up the stack. + + A nice side effect is that we can still debug startup code without + running off the end of the frame chain, assuming that we have usable + debugging information in the startup modules, and if we choose to not + use the block at main, or can't find it for some reason, everything + still works as before. And if we have no startup code debugging + information but we do have usable information for main(), backtraces + from user code don't go wandering off into the startup code. + + To use this method, define your FRAME_CHAIN_VALID macro like: + + #define FRAME_CHAIN_VALID(chain, thisframe) \ + (chain != 0 \ + && !(inside_main_func ((thisframe)->pc)) \ + && !(inside_entry_func ((thisframe)->pc))) + + and add initializations of the four scope controlling variables inside + the object file / debugging information processing modules. */ + +struct entry_info +{ + + /* The value we should use for this objects entry point. + The illegal/unknown value needs to be something other than 0, ~0 + for instance, which is much less likely than 0. */ + + CORE_ADDR entry_point; + +#define INVALID_ENTRY_POINT (~0) /* ~0 will not be in any file, we hope. */ + + /* Start (inclusive) and end (exclusive) of function containing the + entry point. */ + + CORE_ADDR entry_func_lowpc; + CORE_ADDR entry_func_highpc; + + /* Start (inclusive) and end (exclusive) of object file containing the + entry point. */ + + CORE_ADDR entry_file_lowpc; + CORE_ADDR entry_file_highpc; + + /* Start (inclusive) and end (exclusive) of the user code main() function. */ + + CORE_ADDR main_func_lowpc; + CORE_ADDR main_func_highpc; + +/* Use these values when any of the above ranges is invalid. */ + +/* We use these values because it guarantees that there is no number that is + both >= LOWPC && < HIGHPC. It is also highly unlikely that 3 is a valid + module or function start address (as opposed to 0). */ + +#define INVALID_ENTRY_LOWPC (3) +#define INVALID_ENTRY_HIGHPC (1) + +}; + +/* Sections in an objfile. + + It is strange that we have both this notion of "sections" + and the one used by section_offsets. Section as used + here, (currently at least) means a BFD section, and the sections + are set up from the BFD sections in allocate_objfile. + + The sections in section_offsets have their meaning determined by + the symbol format, and they are set up by the sym_offsets function + for that symbol file format. + + I'm not sure this could or should be changed, however. */ + +struct obj_section { + CORE_ADDR addr; /* lowest address in section */ + CORE_ADDR endaddr; /* 1+highest address in section */ + + /* This field is being used for nefarious purposes by syms_from_objfile. + It is said to be redundant with section_offsets; it's not really being + used that way, however, it's some sort of hack I don't understand + and am not going to try to eliminate (yet, anyway). FIXME. + + It was documented as "offset between (end)addr and actual memory + addresses", but that's not true; addr & endaddr are actual memory + addresses. */ + CORE_ADDR offset; + + sec_ptr the_bfd_section; /* BFD section pointer */ + + /* Objfile this section is part of. */ + struct objfile *objfile; + + /* True if this "overlay section" is mapped into an "overlay region". */ + int ovly_mapped; +}; + +/* An import entry contains information about a symbol that + is used in this objfile but not defined in it, and so needs + to be imported from some other objfile */ +/* Currently we just store the name; no attributes. 1997-08-05 */ +typedef char * ImportEntry; + + +/* An export entry contains information about a symbol that + is defined in this objfile and available for use in other + objfiles */ +typedef struct { + char * name; /* name of exported symbol */ + int address; /* offset subject to relocation */ + /* Currently no other attributes 1997-08-05 */ +} ExportEntry; + + + +/* The "objstats" structure provides a place for gdb to record some + interesting information about its internal state at runtime, on a + per objfile basis, such as information about the number of symbols + read, size of string table (if any), etc. */ + +#if MAINTENANCE_CMDS + +struct objstats { + int n_minsyms; /* Number of minimal symbols read */ + int n_psyms; /* Number of partial symbols read */ + int n_syms; /* Number of full symbols read */ + int n_stabs; /* Number of ".stabs" read (if applicable) */ + int n_types; /* Number of types */ + int sz_strtab; /* Size of stringtable, (if applicable) */ +}; + +#define OBJSTAT(objfile, expr) (objfile -> stats.expr) +#define OBJSTATS struct objstats stats +extern void print_objfile_statistics PARAMS ((void)); +extern void print_symbol_bcache_statistics PARAMS ((void)); + +#else + +#define OBJSTAT(objfile, expr) /* Nothing */ +#define OBJSTATS /* Nothing */ + +#endif /* MAINTENANCE_CMDS */ + +/* Master structure for keeping track of each file from which + gdb reads symbols. There are several ways these get allocated: 1. + The main symbol file, symfile_objfile, set by the symbol-file command, + 2. Additional symbol files added by the add-symbol-file command, + 3. Shared library objfiles, added by ADD_SOLIB, 4. symbol files + for modules that were loaded when GDB attached to a remote system + (see remote-vx.c). */ + +struct objfile +{ + + /* All struct objfile's are chained together by their next pointers. + The global variable "object_files" points to the first link in this + chain. + + FIXME: There is a problem here if the objfile is reusable, and if + multiple users are to be supported. The problem is that the objfile + list is linked through a member of the objfile struct itself, which + is only valid for one gdb process. The list implementation needs to + be changed to something like: + + struct list {struct list *next; struct objfile *objfile}; + + where the list structure is completely maintained separately within + each gdb process. */ + + struct objfile *next; + + /* The object file's name. Malloc'd; free it if you free this struct. */ + + char *name; + + /* TRUE if this objfile was created because the user explicitly caused + it (e.g., used the add-symbol-file command). + */ + int user_loaded; + + /* TRUE if this objfile was explicitly created to represent a solib. + + (If FALSE, the objfile may actually be a solib. This can happen if + the user created the objfile by using the add-symbol-file command. + GDB doesn't in that situation actually check whether the file is a + solib. Rather, the target's implementation of the solib interface + is responsible for setting this flag when noticing solibs used by + an inferior.) + */ + int is_solib; + + /* Some flag bits for this objfile. */ + + unsigned short flags; + + /* Each objfile points to a linked list of symtabs derived from this file, + one symtab structure for each compilation unit (source file). Each link + in the symtab list contains a backpointer to this objfile. */ + + struct symtab *symtabs; + + /* Each objfile points to a linked list of partial symtabs derived from + this file, one partial symtab structure for each compilation unit + (source file). */ + + struct partial_symtab *psymtabs; + + /* List of freed partial symtabs, available for re-use */ + + struct partial_symtab *free_psymtabs; + + /* The object file's BFD. Can be null if the objfile contains only + minimal symbols, e.g. the run time common symbols for SunOS4. */ + + bfd *obfd; + + /* The modification timestamp of the object file, as of the last time + we read its symbols. */ + + long mtime; + + /* Obstacks to hold objects that should be freed when we load a new symbol + table from this object file. */ + + struct obstack psymbol_obstack; /* Partial symbols */ + struct obstack symbol_obstack; /* Full symbols */ + struct obstack type_obstack; /* Types */ + + /* A byte cache where we can stash arbitrary "chunks" of bytes that + will not change. */ + + struct bcache psymbol_cache; /* Byte cache for partial syms */ + + /* Vectors of all partial symbols read in from file. The actual data + is stored in the psymbol_obstack. */ + + struct psymbol_allocation_list global_psymbols; + struct psymbol_allocation_list static_psymbols; + + /* Each file contains a pointer to an array of minimal symbols for all + global symbols that are defined within the file. The array is terminated + by a "null symbol", one that has a NULL pointer for the name and a zero + value for the address. This makes it easy to walk through the array + when passed a pointer to somewhere in the middle of it. There is also + a count of the number of symbols, which does not include the terminating + null symbol. The array itself, as well as all the data that it points + to, should be allocated on the symbol_obstack for this file. */ + + struct minimal_symbol *msymbols; + int minimal_symbol_count; + + /* For object file formats which don't specify fundamental types, gdb + can create such types. For now, it maintains a vector of pointers + to these internally created fundamental types on a per objfile basis, + however it really should ultimately keep them on a per-compilation-unit + basis, to account for linkage-units that consist of a number of + compilation units that may have different fundamental types, such as + linking C modules with ADA modules, or linking C modules that are + compiled with 32-bit ints with C modules that are compiled with 64-bit + ints (not inherently evil with a smarter linker). */ + + struct type **fundamental_types; + + /* The mmalloc() malloc-descriptor for this objfile if we are using + the memory mapped malloc() package to manage storage for this objfile's + data. NULL if we are not. */ + + PTR md; + + /* The file descriptor that was used to obtain the mmalloc descriptor + for this objfile. If we call mmalloc_detach with the malloc descriptor + we should then close this file descriptor. */ + + int mmfd; + + /* Structure which keeps track of functions that manipulate objfile's + of the same type as this objfile. I.E. the function to read partial + symbols for example. Note that this structure is in statically + allocated memory, and is shared by all objfiles that use the + object module reader of this type. */ + + struct sym_fns *sf; + + /* The per-objfile information about the entry point, the scope (file/func) + containing the entry point, and the scope of the user's main() func. */ + + struct entry_info ei; + + /* Information about stabs. Will be filled in with a dbx_symfile_info + struct by those readers that need it. */ + + struct dbx_symfile_info *sym_stab_info; + + /* Hook for information for use by the symbol reader (currently used + for information shared by sym_init and sym_read). It is + typically a pointer to malloc'd memory. The symbol reader's finish + function is responsible for freeing the memory thusly allocated. */ + + PTR sym_private; + + /* Hook for target-architecture-specific information. This must + point to memory allocated on one of the obstacks in this objfile, + so that it gets freed automatically when reading a new object + file. */ + + PTR obj_private; + + /* Set of relocation offsets to apply to each section. + Currently on the psymbol_obstack (which makes no sense, but I'm + not sure it's harming anything). + + These offsets indicate that all symbols (including partial and + minimal symbols) which have been read have been relocated by this + much. Symbols which are yet to be read need to be relocated by + it. */ + + struct section_offsets *section_offsets; + int num_sections; + + /* set of section begin and end addresses used to map pc addresses + into sections. Currently on the psymbol_obstack (which makes no + sense, but I'm not sure it's harming anything). */ + + struct obj_section + *sections, + *sections_end; + + /* two auxiliary fields, used to hold the fp of separate symbol files */ + FILE *auxf1, *auxf2; + + /* Imported symbols */ + ImportEntry * import_list; + int import_list_size; + + /* Exported symbols */ + ExportEntry * export_list; + int export_list_size; + + /* Place to stash various statistics about this objfile */ + OBJSTATS; +}; + +/* Defines for the objfile flag word. */ + +/* Gdb can arrange to allocate storage for all objects related to a + particular objfile in a designated section of its address space, + managed at a low level by mmap() and using a special version of + malloc that handles malloc/free/realloc on top of the mmap() interface. + This allows the "internal gdb state" for a particular objfile to be + dumped to a gdb state file and subsequently reloaded at a later time. */ + +#define OBJF_MAPPED (1 << 0) /* Objfile data is mmap'd */ + +/* When using mapped/remapped predigested gdb symbol information, we need + a flag that indicates that we have previously done an initial symbol + table read from this particular objfile. We can't just look for the + absence of any of the three symbol tables (msymbols, psymtab, symtab) + because if the file has no symbols for example, none of these will + exist. */ + +#define OBJF_SYMS (1 << 1) /* Have tried to read symbols */ + +/* When an object file has its functions reordered (currently Irix-5.2 + shared libraries exhibit this behaviour), we will need an expensive + algorithm to locate a partial symtab or symtab via an address. + To avoid this penalty for normal object files, we use this flag, + whose setting is determined upon symbol table read in. */ + +#define OBJF_REORDERED (1 << 2) /* Functions are reordered */ + +/* Distinguish between an objfile for a shared library and a + "vanilla" objfile. */ + +#define OBJF_SHARED (1 << 3) /* From a shared library */ + +/* The object file that the main symbol table was loaded from (e.g. the + argument to the "symbol-file" or "file" command). */ + +extern struct objfile *symfile_objfile; + +/* The object file that contains the runtime common minimal symbols + for SunOS4. Note that this objfile has no associated BFD. */ + +extern struct objfile *rt_common_objfile; + +/* When we need to allocate a new type, we need to know which type_obstack + to allocate the type on, since there is one for each objfile. The places + where types are allocated are deeply buried in function call hierarchies + which know nothing about objfiles, so rather than trying to pass a + particular objfile down to them, we just do an end run around them and + set current_objfile to be whatever objfile we expect to be using at the + time types are being allocated. For instance, when we start reading + symbols for a particular objfile, we set current_objfile to point to that + objfile, and when we are done, we set it back to NULL, to ensure that we + never put a type someplace other than where we are expecting to put it. + FIXME: Maybe we should review the entire type handling system and + see if there is a better way to avoid this problem. */ + +extern struct objfile *current_objfile; + +/* All known objfiles are kept in a linked list. This points to the + root of this list. */ + +extern struct objfile *object_files; + +/* Declarations for functions defined in objfiles.c */ + +extern struct objfile * +allocate_objfile PARAMS ((bfd *, int, int, int)); + +extern int +build_objfile_section_table PARAMS ((struct objfile *)); + +extern void objfile_to_front PARAMS ((struct objfile *)); + +extern void +unlink_objfile PARAMS ((struct objfile *)); + +extern void +free_objfile PARAMS ((struct objfile *)); + +extern void +free_all_objfiles PARAMS ((void)); + +extern void +objfile_relocate PARAMS ((struct objfile *, struct section_offsets *)); + +extern int +have_partial_symbols PARAMS ((void)); + +extern int +have_full_symbols PARAMS ((void)); + +/* This operation deletes all objfile entries that represent solibs that + weren't explicitly loaded by the user, via e.g., the add-symbol-file + command. + */ +extern void +objfile_purge_solibs PARAMS ((void)); + +/* Functions for dealing with the minimal symbol table, really a misc + address<->symbol mapping for things we don't have debug symbols for. */ + +extern int +have_minimal_symbols PARAMS ((void)); + +extern struct obj_section * +find_pc_section PARAMS((CORE_ADDR pc)); + +extern struct obj_section * +find_pc_sect_section PARAMS((CORE_ADDR pc, asection *section)); + +extern int +in_plt_section PARAMS ((CORE_ADDR, char *)); + +/* Traverse all object files. ALL_OBJFILES_SAFE works even if you delete + the objfile during the traversal. */ + +#define ALL_OBJFILES(obj) \ + for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next) + +#define ALL_OBJFILES_SAFE(obj,nxt) \ + for ((obj) = object_files; \ + (obj) != NULL? ((nxt)=(obj)->next,1) :0; \ + (obj) = (nxt)) + +/* Traverse all symtabs in one objfile. */ + +#define ALL_OBJFILE_SYMTABS(objfile, s) \ + for ((s) = (objfile) -> symtabs; (s) != NULL; (s) = (s) -> next) + +/* Traverse all psymtabs in one objfile. */ + +#define ALL_OBJFILE_PSYMTABS(objfile, p) \ + for ((p) = (objfile) -> psymtabs; (p) != NULL; (p) = (p) -> next) + +/* Traverse all minimal symbols in one objfile. */ + +#define ALL_OBJFILE_MSYMBOLS(objfile, m) \ + for ((m) = (objfile) -> msymbols; SYMBOL_NAME(m) != NULL; (m)++) + +/* Traverse all symtabs in all objfiles. */ + +#define ALL_SYMTABS(objfile, s) \ + ALL_OBJFILES (objfile) \ + ALL_OBJFILE_SYMTABS (objfile, s) + +/* Traverse all psymtabs in all objfiles. */ + +#define ALL_PSYMTABS(objfile, p) \ + ALL_OBJFILES (objfile) \ + ALL_OBJFILE_PSYMTABS (objfile, p) + +/* Traverse all minimal symbols in all objfiles. */ + +#define ALL_MSYMBOLS(objfile, m) \ + ALL_OBJFILES (objfile) \ + if ((objfile)->msymbols) \ + ALL_OBJFILE_MSYMBOLS (objfile, m) + +#define ALL_OBJFILE_OSECTIONS(objfile, osect) \ + for (osect = objfile->sections; osect < objfile->sections_end; osect++) + +#define ALL_OBJSECTIONS(objfile, osect) \ + ALL_OBJFILES (objfile) \ + ALL_OBJFILE_OSECTIONS (objfile, osect) + +#endif /* !defined (OBJFILES_H) */ |