Initial creation of sourceware repository

1 files changed, 0 insertions, 572 deletions

diff --git a/gdb/objfiles.h b/gdb/objfiles.h
deleted file mode 100644
index 2a5df06..0000000
--- a/gdb/objfiles.h
+++ /dev/null
@@ -1,572 +0,0 @@
-/* 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) */