bf349b77fa
tried to read symbols from a file, for mapped objfiles. This fixes a memory leak (actually a constant memory growth) due to reading symbol files with no debug info and thus generating no psymtabs or symtabs. Most typically happened with shared libraries.
323 lines
13 KiB
C
323 lines
13 KiB
C
/* Definitions for symbol file management in GDB.
|
|
Copyright (C) 1992 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., 675 Mass Ave, Cambridge, MA 02139, 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 it's 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 (or top, depending
|
|
upon your stack orientation).
|
|
|
|
Gdb also supports an alternate method to avoid running off the top/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;
|
|
|
|
/* 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;
|
|
|
|
};
|
|
|
|
|
|
/* 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. */
|
|
|
|
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. */
|
|
|
|
struct objfile *next;
|
|
|
|
/* The object file's name. Malloc'd; free it if you free this struct. */
|
|
|
|
char *name;
|
|
|
|
/* 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, in which case bfd_open (name) and
|
|
put the result here. */
|
|
|
|
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 */
|
|
|
|
/* 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 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;
|
|
|
|
/* 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;
|
|
|
|
/* Hook for information which is shared by sym_init and sym_read for
|
|
this objfile. It is typically a pointer to malloc'd memory. */
|
|
|
|
PTR sym_private;
|
|
|
|
};
|
|
|
|
/* 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 it's 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 */
|
|
|
|
/* 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;
|
|
|
|
/* 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));
|
|
|
|
extern void
|
|
free_objfile PARAMS ((struct objfile *));
|
|
|
|
extern void
|
|
free_all_objfiles PARAMS ((void));
|
|
|
|
extern int
|
|
have_partial_symbols PARAMS ((void));
|
|
|
|
extern int
|
|
have_full_symbols 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 PTR
|
|
iterate_over_objfiles PARAMS ((PTR (*func) (struct objfile *,
|
|
PTR arg1, PTR arg2, PTR arg3),
|
|
PTR arg1, PTR arg2, PTR arg3));
|
|
|
|
extern PTR
|
|
iterate_over_symtabs PARAMS ((PTR (*func) (struct objfile *, struct symtab *,
|
|
PTR arg1, PTR arg2, PTR arg3),
|
|
PTR arg1, PTR arg2, PTR arg3));
|
|
|
|
extern PTR
|
|
iterate_over_psymtabs PARAMS ((PTR (*func) (struct objfile *,
|
|
struct partial_symtab *,
|
|
PTR arg1, PTR arg2, PTR arg3),
|
|
PTR arg1, PTR arg2, PTR arg3));
|
|
|
|
|
|
/* 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))
|
|
|
|
#endif /* !defined (OBJFILES_H) */
|