2004-01-19 Andrew Cagney <cagney@redhat.com>

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

diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index c52b95faa87ed8f8be4ebfe536315b67d66e84d9..732af4d3d010288f16838c46735b4bb10f63cd05 100644 (file)
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -29,6 +29,7 @@
 struct bcache;
 struct htab;
 struct symtab;
+struct objfile_data;
 
 /* This structure maintains information on a per-objfile basis about the
    "entry point" of the objfile, and the scope within which the entry point
@@ -43,14 +44,28 @@ struct symtab;
    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.
+   The traditional gdb method of using this info is to use the
+   recorded entry point to set the variables
+   deprecated_entry_file_lowpc and deprecated_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.
+
+   NOTE: cagney/2003-09-09: It turns out that this "traditional"
+   method doesn't work.  Corinna writes: ``It turns out that the call
+   to deprecated_inside_entry_file destroys a meaningful backtrace
+   under some conditions.  E. g. the backtrace tests in the asm-source
+   testcase are broken for some targets.  In this test the functions
+   are all implemented as part of one file and the testcase is not
+   necessarily linked with a start file (depending on the target).
+   What happens is, that the first frame is printed normaly and
+   following frames are treated as being inside the enttry file then.
+   This way, only the #0 frame is printed in the backtrace output.''
+   Ref "frame.c" "NOTE: vinschen/2003-04-01".
 
    Gdb also supports an alternate method to avoid running off the bottom
    of the stack.
@@ -116,8 +131,8 @@ struct entry_info
     /* Start (inclusive) and end (exclusive) of object file containing the
        entry point. */
 
-    CORE_ADDR entry_file_lowpc;
-    CORE_ADDR entry_file_highpc;
+    CORE_ADDR deprecated_entry_file_lowpc;
+    CORE_ADDR deprecated_entry_file_highpc;
 
     /* Start (inclusive) and end (exclusive) of the user code main() function. */
 
@@ -163,7 +178,7 @@ struct obj_section
        addresses.  */
     CORE_ADDR offset;
 
-    sec_ptr the_bfd_section;   /* BFD section pointer */
+    struct bfd_section *the_bfd_section;       /* BFD section pointer */
 
     /* Objfile this section is part of.  */
     struct objfile *objfile;
@@ -455,15 +470,6 @@ struct objfile
 
 /* 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
@@ -584,6 +590,7 @@ extern int is_in_import_list (char *, struct objfile *);
    modules.  */
 
 extern const struct objfile_data *register_objfile_data (void);
+extern void clear_objfile_data (struct objfile *objfile);
 extern void set_objfile_data (struct objfile *objfile,
                              const struct objfile_data *data, void *value);
 extern void *objfile_data (struct objfile *objfile,