* serial.h (SERIAL_SET_TTY_STATE): Comment return value.

[deliverable/binutils-gdb.git] / gdb / objfiles.h

diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index 3cc5de15de59a3c5ca9048032a500265541af0c8..6cff2cad93e58ef5d483e225108919b2c473aca7 100644 (file)
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -40,10 +40,9 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
    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 (or top, depending
-   upon your stack orientation).
+   so that backtraces do not fly off the bottom of the stack.
 
-   Gdb also supports an alternate method to avoid running off the top/bottom
+   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
@@ -114,22 +113,48 @@ struct entry_info
 };
 
 
-/* This structure is used to map pc values into sections.  Note that
-   offset is currently target independent and is redundant to the
-   section_offsets field in the objfile struct.  FIXME.  */
+/* 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 */
-  CORE_ADDR    offset;  /* offset between (end)addr and actual
-                           memory addresses.  */
+
+  /* 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      sec_ptr; /* BFD section pointer */
+
+  /* Objfile this section is part of.  Not currently used, but I'm sure
+     that someone will want the bfd that the sec_ptr goes with or something
+     like that before long.  */
+  struct objfile *objfile;
 };
 
-/* Master structure for keeping track of each input file from which
-   gdb reads symbols.  One of these is allocated for each such file we
-   access, e.g. the exec_file, symbol_file, and any shared library object
-   files. */
+/* 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
 {
@@ -247,14 +272,22 @@ struct objfile
 
   struct entry_info ei;
 
-  /* Hook for information which is shared by sym_init and sym_read for
-     this objfile.  It is typically a pointer to malloc'd memory.  */
+  /* Information about stabs.  Will be filled in with a dbx_symfile_info
+     struct by those readers that need it. */
+
+  PTR 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 other info specific to this objfile.  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. */
+  /* 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;
 
@@ -326,14 +359,13 @@ extern struct objfile *object_files;
 
 /* Declarations for functions defined in objfiles.c */
 
-extern struct objfile *
-allocate_objfile PARAMS ((bfd *, int));
+extern struct objfile *allocate_objfile PARAMS ((bfd *, int));
 
-extern void
-unlink_objfile PARAMS ((struct objfile *));
+int build_objfile_section_table PARAMS ((struct objfile *));
 
-extern void
-free_objfile PARAMS ((struct objfile *));
+extern void unlink_objfile PARAMS ((struct objfile *));
+
+extern void free_objfile PARAMS ((struct objfile *));
 
 extern void
 free_all_objfiles PARAMS ((void));
@@ -353,7 +385,7 @@ have_full_symbols PARAMS ((void));
 extern int
 have_minimal_symbols PARAMS ((void));
 
-extern sec_ptr
+extern struct obj_section *
 find_pc_section PARAMS((CORE_ADDR pc));
 
 /* Traverse all object files.  ALL_OBJFILES_SAFE works even if you delete