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