]> Git Repo - binutils.git/blob - gdb/objfiles.h
remove parentdir support
[binutils.git] / gdb / objfiles.h
1 /* Definitions for symbol file management in GDB.
2    Copyright (C) 1992 Free Software Foundation, Inc.
3
4 This file is part of GDB.
5
6 This program is free software; you can redistribute it and/or modify
7 it under the terms of the GNU General Public License as published by
8 the Free Software Foundation; either version 2 of the License, or
9 (at your option) any later version.
10
11 This program is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
14 GNU General Public License for more details.
15
16 You should have received a copy of the GNU General Public License
17 along with this program; if not, write to the Free Software
18 Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
19
20 #if !defined (OBJFILES_H)
21 #define OBJFILES_H
22
23 /* This structure maintains information on a per-objfile basis about the
24    "entry point" of the objfile, and the scope within which the entry point
25    exists.  It is possible that gdb will see more than one objfile that is
26    executable, each with it's own entry point.
27
28    For example, for dynamically linked executables in SVR4, the dynamic linker
29    code is contained within the shared C library, which is actually executable
30    and is run by the kernel first when an exec is done of a user executable
31    that is dynamically linked.  The dynamic linker within the shared C library
32    then maps in the various program segments in the user executable and jumps
33    to the user executable's recorded entry point, as if the call had been made
34    directly by the kernel.
35
36    The traditional gdb method of using this info is to use the recorded entry
37    point to set the variables entry_file_lowpc and entry_file_highpc from
38    the debugging information, where these values are the starting address
39    (inclusive) and ending address (exclusive) of the instruction space in the
40    executable which correspond to the "startup file", I.E. crt0.o in most
41    cases.  This file is assumed to be a startup file and frames with pc's
42    inside it are treated as nonexistent.  Setting these variables is necessary
43    so that backtraces do not fly off the bottom of the stack (or top, depending
44    upon your stack orientation).
45
46    Gdb also supports an alternate method to avoid running off the top/bottom
47    of the stack.
48
49    There are two frames that are "special", the frame for the function
50    containing the process entry point, since it has no predecessor frame,
51    and the frame for the function containing the user code entry point
52    (the main() function), since all the predecessor frames are for the
53    process startup code.  Since we have no guarantee that the linked
54    in startup modules have any debugging information that gdb can use,
55    we need to avoid following frame pointers back into frames that might
56    have been built in the startup code, as we might get hopelessly 
57    confused.  However, we almost always have debugging information
58    available for main().
59
60    These variables are used to save the range of PC values which are valid
61    within the main() function and within the function containing the process
62    entry point.  If we always consider the frame for main() as the outermost
63    frame when debugging user code, and the frame for the process entry
64    point function as the outermost frame when debugging startup code, then
65    all we have to do is have FRAME_CHAIN_VALID return false whenever a
66    frame's current PC is within the range specified by these variables.
67    In essence, we set "ceilings" in the frame chain beyond which we will
68    not proceed when following the frame chain back up the stack.
69
70    A nice side effect is that we can still debug startup code without
71    running off the end of the frame chain, assuming that we have usable
72    debugging information in the startup modules, and if we choose to not
73    use the block at main, or can't find it for some reason, everything
74    still works as before.  And if we have no startup code debugging
75    information but we do have usable information for main(), backtraces
76    from user code don't go wandering off into the startup code.
77
78    To use this method, define your FRAME_CHAIN_VALID macro like:
79
80         #define FRAME_CHAIN_VALID(chain, thisframe)     \
81           (chain != 0                                   \
82            && !(inside_main_func ((thisframe)->pc))     \
83            && !(inside_entry_func ((thisframe)->pc)))
84
85    and add initializations of the four scope controlling variables inside
86    the object file / debugging information processing modules.  */
87
88 struct entry_info
89 {
90   
91   /* The value we should use for this objects entry point.
92      The illegal/unknown value needs to be something other than 0, ~0
93      for instance, which is much less likely than 0. */
94
95   CORE_ADDR entry_point;
96
97   /* Start (inclusive) and end (exclusive) of function containing the
98      entry point. */
99
100   CORE_ADDR entry_func_lowpc;
101   CORE_ADDR entry_func_highpc;
102
103   /* Start (inclusive) and end (exclusive) of object file containing the
104      entry point. */
105   
106   CORE_ADDR entry_file_lowpc;
107   CORE_ADDR entry_file_highpc;
108
109   /* Start (inclusive) and end (exclusive) of the user code main() function. */
110
111   CORE_ADDR main_func_lowpc;
112   CORE_ADDR main_func_highpc;
113
114 };
115
116
117 /* Sections in an objfile.
118
119    It is strange that we have both this notion of "sections"
120    and the one used by section_offsets.  Section as used
121    here, (currently at least) means a BFD section, and the sections
122    are set up from the BFD sections in allocate_objfile.
123
124    The sections in section_offsets have their meaning determined by
125    the symbol format, and they are set up by the sym_offsets function
126    for that symbol file format.
127
128    I'm not sure this could or should be changed, however.  */
129
130 struct obj_section {
131   CORE_ADDR     addr;    /* lowest address in section */
132   CORE_ADDR     endaddr; /* 1+highest address in section */
133
134   /* This field is being used for nefarious purposes by syms_from_objfile.
135      It is said to be redundant with section_offsets; it's not really being
136      used that way, however, it's some sort of hack I don't understand
137      and am not going to try to eliminate (yet, anyway).  FIXME.
138
139      It was documented as "offset between (end)addr and actual memory
140      addresses", but that's not true; addr & endaddr are actual memory
141      addresses.  */
142   CORE_ADDR offset;
143      
144   sec_ptr       sec_ptr; /* BFD section pointer */
145
146   /* Objfile this section is part of.  Not currently used, but I'm sure
147      that someone will want the bfd that the sec_ptr goes with or something
148      like that before long.  */
149   struct objfile *objfile;
150 };
151
152 /* Master structure for keeping track of each input file from which
153    gdb reads symbols.  One of these is allocated for each such file we
154    access, e.g. the exec_file, symbol_file, and any shared library object
155    files. */
156
157 struct objfile
158 {
159
160   /* All struct objfile's are chained together by their next pointers.
161      The global variable "object_files" points to the first link in this
162      chain.
163
164      FIXME:  There is a problem here if the objfile is reusable, and if
165      multiple users are to be supported.  The problem is that the objfile
166      list is linked through a member of the objfile struct itself, which
167      is only valid for one gdb process.  The list implementation needs to
168      be changed to something like:
169
170      struct list {struct list *next; struct objfile *objfile};
171
172      where the list structure is completely maintained separately within
173      each gdb process. */
174
175   struct objfile *next;
176
177   /* The object file's name.  Malloc'd; free it if you free this struct.  */
178
179   char *name;
180
181   /* Some flag bits for this objfile. */
182
183   unsigned short flags;
184
185   /* Each objfile points to a linked list of symtabs derived from this file,
186      one symtab structure for each compilation unit (source file).  Each link
187      in the symtab list contains a backpointer to this objfile. */
188
189   struct symtab *symtabs;
190
191   /* Each objfile points to a linked list of partial symtabs derived from
192      this file, one partial symtab structure for each compilation unit
193      (source file). */
194
195   struct partial_symtab *psymtabs;
196
197   /* List of freed partial symtabs, available for re-use */
198
199   struct partial_symtab *free_psymtabs;
200
201   /* The object file's BFD.  Can be null, in which case bfd_open (name) and
202      put the result here.  */
203
204   bfd *obfd;
205
206   /* The modification timestamp of the object file, as of the last time
207      we read its symbols.  */
208
209   long mtime;
210
211   /* Obstacks to hold objects that should be freed when we load a new symbol
212      table from this object file. */
213
214   struct obstack psymbol_obstack;       /* Partial symbols */
215   struct obstack symbol_obstack;        /* Full symbols */
216   struct obstack type_obstack;          /* Types */
217
218   /* Vectors of all partial symbols read in from file.  The actual data
219      is stored in the psymbol_obstack. */
220
221   struct psymbol_allocation_list global_psymbols;
222   struct psymbol_allocation_list static_psymbols;
223
224   /* Each file contains a pointer to an array of minimal symbols for all
225      global symbols that are defined within the file.  The array is terminated
226      by a "null symbol", one that has a NULL pointer for the name and a zero
227      value for the address.  This makes it easy to walk through the array
228      when passed a pointer to somewhere in the middle of it.  There is also
229      a count of the number of symbols, which does include the terminating
230      null symbol.  The array itself, as well as all the data that it points
231      to, should be allocated on the symbol_obstack for this file. */
232
233   struct minimal_symbol *msymbols;
234   int minimal_symbol_count;
235
236   /* For object file formats which don't specify fundamental types, gdb
237      can create such types.  For now, it maintains a vector of pointers
238      to these internally created fundamental types on a per objfile basis,
239      however it really should ultimately keep them on a per-compilation-unit
240      basis, to account for linkage-units that consist of a number of
241      compilation units that may have different fundamental types, such as
242      linking C modules with ADA modules, or linking C modules that are
243      compiled with 32-bit ints with C modules that are compiled with 64-bit
244      ints (not inherently evil with a smarter linker). */
245
246   struct type **fundamental_types;
247
248   /* The mmalloc() malloc-descriptor for this objfile if we are using
249      the memory mapped malloc() package to manage storage for this objfile's
250      data.  NULL if we are not. */
251
252   PTR md;
253
254   /* The file descriptor that was used to obtain the mmalloc descriptor
255      for this objfile.  If we call mmalloc_detach with the malloc descriptor
256      we should then close this file descriptor. */
257
258   int mmfd;
259
260   /* Structure which keeps track of functions that manipulate objfile's
261      of the same type as this objfile.  I.E. the function to read partial
262      symbols for example.  Note that this structure is in statically
263      allocated memory, and is shared by all objfiles that use the
264      object module reader of this type. */
265
266   struct sym_fns *sf;
267
268   /* The per-objfile information about the entry point, the scope (file/func)
269      containing the entry point, and the scope of the user's main() func. */
270
271   struct entry_info ei;
272
273   /* Hook for information which is shared by sym_init and sym_read for
274      this objfile.  It is typically a pointer to malloc'd memory.  */
275
276   PTR sym_private;
277
278   /* Hook for other info specific to this objfile.  This must point to
279      memory allocated on one of the obstacks in this objfile, so that it
280      gets freed automatically when reading a new object file. */
281
282   PTR obj_private;
283
284   /* Set of relocation offsets to apply to each section.
285      Currently on the psymbol_obstack (which makes no sense, but I'm
286      not sure it's harming anything).
287
288      These offsets indicate that all symbols (including partial and
289      minimal symbols) which have been read have been relocated by this
290      much.  Symbols which are yet to be read need to be relocated by
291      it.  */
292
293   struct section_offsets *section_offsets;
294   int num_sections;
295
296   /* set of section begin and end addresses used to map pc addresses
297      into sections.  Currently on the psymbol_obstack (which makes no
298      sense, but I'm not sure it's harming anything).  */
299
300   struct obj_section
301     *sections,
302     *sections_end;
303 };
304
305 /* Defines for the objfile flag word. */
306
307 /* Gdb can arrange to allocate storage for all objects related to a
308    particular objfile in a designated section of it's address space,
309    managed at a low level by mmap() and using a special version of
310    malloc that handles malloc/free/realloc on top of the mmap() interface.
311    This allows the "internal gdb state" for a particular objfile to be
312    dumped to a gdb state file and subsequently reloaded at a later time. */
313
314 #define OBJF_MAPPED     (1 << 0)        /* Objfile data is mmap'd */
315
316 /* When using mapped/remapped predigested gdb symbol information, we need
317    a flag that indicates that we have previously done an initial symbol
318    table read from this particular objfile.  We can't just look for the
319    absence of any of the three symbol tables (msymbols, psymtab, symtab)
320    because if the file has no symbols for example, none of these will
321    exist. */
322
323 #define OBJF_SYMS       (1 << 1)        /* Have tried to read symbols */
324
325 /* The object file that the main symbol table was loaded from (e.g. the
326    argument to the "symbol-file" or "file" command).  */
327
328 extern struct objfile *symfile_objfile;
329
330 /* When we need to allocate a new type, we need to know which type_obstack
331    to allocate the type on, since there is one for each objfile.  The places
332    where types are allocated are deeply buried in function call hierarchies
333    which know nothing about objfiles, so rather than trying to pass a
334    particular objfile down to them, we just do an end run around them and
335    set current_objfile to be whatever objfile we expect to be using at the
336    time types are being allocated.  For instance, when we start reading
337    symbols for a particular objfile, we set current_objfile to point to that
338    objfile, and when we are done, we set it back to NULL, to ensure that we
339    never put a type someplace other than where we are expecting to put it.
340    FIXME:  Maybe we should review the entire type handling system and
341    see if there is a better way to avoid this problem. */
342
343 extern struct objfile *current_objfile;
344
345 /* All known objfiles are kept in a linked list.  This points to the
346    root of this list. */
347
348 extern struct objfile *object_files;
349
350 /* Declarations for functions defined in objfiles.c */
351
352 extern struct objfile *
353 allocate_objfile PARAMS ((bfd *, int));
354
355 extern void
356 unlink_objfile PARAMS ((struct objfile *));
357
358 extern void
359 free_objfile PARAMS ((struct objfile *));
360
361 extern void
362 free_all_objfiles PARAMS ((void));
363
364 extern void
365 objfile_relocate PARAMS ((struct objfile *, struct section_offsets *));
366
367 extern int
368 have_partial_symbols PARAMS ((void));
369
370 extern int
371 have_full_symbols PARAMS ((void));
372
373 /* Functions for dealing with the minimal symbol table, really a misc
374    address<->symbol mapping for things we don't have debug symbols for.  */
375
376 extern int
377 have_minimal_symbols PARAMS ((void));
378
379 extern struct obj_section *
380 find_pc_section PARAMS((CORE_ADDR pc));
381
382 /* Traverse all object files.  ALL_OBJFILES_SAFE works even if you delete
383    the objfile during the traversal.  */
384
385 #define ALL_OBJFILES(obj) \
386   for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)
387
388 #define ALL_OBJFILES_SAFE(obj,nxt) \
389   for ((obj) = object_files;       \
390        (obj) != NULL? ((nxt)=(obj)->next,1) :0; \
391        (obj) = (nxt))
392
393
394 /* Traverse all symtabs in one objfile.  */
395
396 #define ALL_OBJFILE_SYMTABS(objfile, s) \
397     for ((s) = (objfile) -> symtabs; (s) != NULL; (s) = (s) -> next)
398
399 /* Traverse all psymtabs in one objfile.  */
400
401 #define ALL_OBJFILE_PSYMTABS(objfile, p) \
402     for ((p) = (objfile) -> psymtabs; (p) != NULL; (p) = (p) -> next)
403
404 /* Traverse all minimal symbols in one objfile.  */
405
406 #define ALL_OBJFILE_MSYMBOLS(objfile, m) \
407     for ((m) = (objfile) -> msymbols; SYMBOL_NAME(m) != NULL; (m)++)
408
409
410 /* Traverse all symtabs in all objfiles.  */
411
412 #define ALL_SYMTABS(objfile, s) \
413   ALL_OBJFILES (objfile)         \
414     ALL_OBJFILE_SYMTABS (objfile, s)
415
416 /* Traverse all psymtabs in all objfiles.  */
417
418 #define ALL_PSYMTABS(objfile, p) \
419   ALL_OBJFILES (objfile)         \
420     ALL_OBJFILE_PSYMTABS (objfile, p)
421
422 /* Traverse all minimal symbols in all objfiles.  */
423
424 #define ALL_MSYMBOLS(objfile, m) \
425   ALL_OBJFILES (objfile)         \
426     if ((objfile)->msymbols)     \
427       ALL_OBJFILE_MSYMBOLS (objfile, m)
428
429 #endif  /* !defined (OBJFILES_H) */
This page took 0.050321 seconds and 4 git commands to generate.