| 1 | /* Definitions for symbol file management in GDB. |
| 2 | Copyright (C) 1992, 1993, 1994, 1995 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, 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 its 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. |
| 44 | |
| 45 | Gdb also supports an alternate method to avoid running off the bottom |
| 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 | |
| 96 | #define INVALID_ENTRY_POINT (~0) /* ~0 will not be in any file, we hope. */ |
| 97 | |
| 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 | |
| 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 | |
| 124 | }; |
| 125 | |
| 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. */ |
| 138 | |
| 139 | struct obj_section { |
| 140 | CORE_ADDR addr; /* lowest address in section */ |
| 141 | CORE_ADDR endaddr; /* 1+highest address in section */ |
| 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; |
| 152 | |
| 153 | sec_ptr the_bfd_section; /* BFD section pointer */ |
| 154 | |
| 155 | /* Objfile this section is part of. */ |
| 156 | struct objfile *objfile; |
| 157 | |
| 158 | /* True if this "overlay section" is mapped into an "overlay region". */ |
| 159 | int ovly_mapped; |
| 160 | }; |
| 161 | |
| 162 | /* The "objstats" structure provides a place for gdb to record some |
| 163 | interesting information about its internal state at runtime, on a |
| 164 | per objfile basis, such as information about the number of symbols |
| 165 | read, size of string table (if any), etc. */ |
| 166 | |
| 167 | #if MAINTENANCE_CMDS |
| 168 | |
| 169 | struct objstats { |
| 170 | int n_minsyms; /* Number of minimal symbols read */ |
| 171 | int n_psyms; /* Number of partial symbols read */ |
| 172 | int n_syms; /* Number of full symbols read */ |
| 173 | int n_stabs; /* Number of ".stabs" read (if applicable) */ |
| 174 | int n_types; /* Number of types */ |
| 175 | int sz_strtab; /* Size of stringtable, (if applicable) */ |
| 176 | }; |
| 177 | |
| 178 | #define OBJSTAT(objfile, expr) (objfile -> stats.expr) |
| 179 | #define OBJSTATS struct objstats stats |
| 180 | extern void print_objfile_statistics PARAMS ((void)); |
| 181 | extern void print_symbol_bcache_statistics PARAMS ((void)); |
| 182 | |
| 183 | #else |
| 184 | |
| 185 | #define OBJSTAT(objfile, expr) /* Nothing */ |
| 186 | #define OBJSTATS /* Nothing */ |
| 187 | |
| 188 | #endif /* MAINTENANCE_CMDS */ |
| 189 | |
| 190 | /* Master structure for keeping track of each file from which |
| 191 | gdb reads symbols. There are several ways these get allocated: 1. |
| 192 | The main symbol file, symfile_objfile, set by the symbol-file command, |
| 193 | 2. Additional symbol files added by the add-symbol-file command, |
| 194 | 3. Shared library objfiles, added by ADD_SOLIB, 4. symbol files |
| 195 | for modules that were loaded when GDB attached to a remote system |
| 196 | (see remote-vx.c). */ |
| 197 | |
| 198 | struct objfile |
| 199 | { |
| 200 | |
| 201 | /* All struct objfile's are chained together by their next pointers. |
| 202 | The global variable "object_files" points to the first link in this |
| 203 | chain. |
| 204 | |
| 205 | FIXME: There is a problem here if the objfile is reusable, and if |
| 206 | multiple users are to be supported. The problem is that the objfile |
| 207 | list is linked through a member of the objfile struct itself, which |
| 208 | is only valid for one gdb process. The list implementation needs to |
| 209 | be changed to something like: |
| 210 | |
| 211 | struct list {struct list *next; struct objfile *objfile}; |
| 212 | |
| 213 | where the list structure is completely maintained separately within |
| 214 | each gdb process. */ |
| 215 | |
| 216 | struct objfile *next; |
| 217 | |
| 218 | /* The object file's name. Malloc'd; free it if you free this struct. */ |
| 219 | |
| 220 | char *name; |
| 221 | |
| 222 | /* Some flag bits for this objfile. */ |
| 223 | |
| 224 | unsigned short flags; |
| 225 | |
| 226 | /* Each objfile points to a linked list of symtabs derived from this file, |
| 227 | one symtab structure for each compilation unit (source file). Each link |
| 228 | in the symtab list contains a backpointer to this objfile. */ |
| 229 | |
| 230 | struct symtab *symtabs; |
| 231 | |
| 232 | /* Each objfile points to a linked list of partial symtabs derived from |
| 233 | this file, one partial symtab structure for each compilation unit |
| 234 | (source file). */ |
| 235 | |
| 236 | struct partial_symtab *psymtabs; |
| 237 | |
| 238 | /* List of freed partial symtabs, available for re-use */ |
| 239 | |
| 240 | struct partial_symtab *free_psymtabs; |
| 241 | |
| 242 | /* The object file's BFD. Can be null if the objfile contains only |
| 243 | minimal symbols, e.g. the run time common symbols for SunOS4. */ |
| 244 | |
| 245 | bfd *obfd; |
| 246 | |
| 247 | /* The modification timestamp of the object file, as of the last time |
| 248 | we read its symbols. */ |
| 249 | |
| 250 | long mtime; |
| 251 | |
| 252 | /* Obstacks to hold objects that should be freed when we load a new symbol |
| 253 | table from this object file. */ |
| 254 | |
| 255 | struct obstack psymbol_obstack; /* Partial symbols */ |
| 256 | struct obstack symbol_obstack; /* Full symbols */ |
| 257 | struct obstack type_obstack; /* Types */ |
| 258 | |
| 259 | /* A byte cache where we can stash arbitrary "chunks" of bytes that |
| 260 | will not change. */ |
| 261 | |
| 262 | struct bcache psymbol_cache; /* Byte cache for partial syms */ |
| 263 | |
| 264 | /* Vectors of all partial symbols read in from file. The actual data |
| 265 | is stored in the psymbol_obstack. */ |
| 266 | |
| 267 | struct psymbol_allocation_list global_psymbols; |
| 268 | struct psymbol_allocation_list static_psymbols; |
| 269 | |
| 270 | /* Each file contains a pointer to an array of minimal symbols for all |
| 271 | global symbols that are defined within the file. The array is terminated |
| 272 | by a "null symbol", one that has a NULL pointer for the name and a zero |
| 273 | value for the address. This makes it easy to walk through the array |
| 274 | when passed a pointer to somewhere in the middle of it. There is also |
| 275 | a count of the number of symbols, which does not include the terminating |
| 276 | null symbol. The array itself, as well as all the data that it points |
| 277 | to, should be allocated on the symbol_obstack for this file. */ |
| 278 | |
| 279 | struct minimal_symbol *msymbols; |
| 280 | int minimal_symbol_count; |
| 281 | |
| 282 | /* For object file formats which don't specify fundamental types, gdb |
| 283 | can create such types. For now, it maintains a vector of pointers |
| 284 | to these internally created fundamental types on a per objfile basis, |
| 285 | however it really should ultimately keep them on a per-compilation-unit |
| 286 | basis, to account for linkage-units that consist of a number of |
| 287 | compilation units that may have different fundamental types, such as |
| 288 | linking C modules with ADA modules, or linking C modules that are |
| 289 | compiled with 32-bit ints with C modules that are compiled with 64-bit |
| 290 | ints (not inherently evil with a smarter linker). */ |
| 291 | |
| 292 | struct type **fundamental_types; |
| 293 | |
| 294 | /* The mmalloc() malloc-descriptor for this objfile if we are using |
| 295 | the memory mapped malloc() package to manage storage for this objfile's |
| 296 | data. NULL if we are not. */ |
| 297 | |
| 298 | PTR md; |
| 299 | |
| 300 | /* The file descriptor that was used to obtain the mmalloc descriptor |
| 301 | for this objfile. If we call mmalloc_detach with the malloc descriptor |
| 302 | we should then close this file descriptor. */ |
| 303 | |
| 304 | int mmfd; |
| 305 | |
| 306 | /* Structure which keeps track of functions that manipulate objfile's |
| 307 | of the same type as this objfile. I.E. the function to read partial |
| 308 | symbols for example. Note that this structure is in statically |
| 309 | allocated memory, and is shared by all objfiles that use the |
| 310 | object module reader of this type. */ |
| 311 | |
| 312 | struct sym_fns *sf; |
| 313 | |
| 314 | /* The per-objfile information about the entry point, the scope (file/func) |
| 315 | containing the entry point, and the scope of the user's main() func. */ |
| 316 | |
| 317 | struct entry_info ei; |
| 318 | |
| 319 | /* Information about stabs. Will be filled in with a dbx_symfile_info |
| 320 | struct by those readers that need it. */ |
| 321 | |
| 322 | struct dbx_symfile_info *sym_stab_info; |
| 323 | |
| 324 | /* Hook for information for use by the symbol reader (currently used |
| 325 | for information shared by sym_init and sym_read). It is |
| 326 | typically a pointer to malloc'd memory. The symbol reader's finish |
| 327 | function is responsible for freeing the memory thusly allocated. */ |
| 328 | |
| 329 | PTR sym_private; |
| 330 | |
| 331 | /* Hook for target-architecture-specific information. This must |
| 332 | point to memory allocated on one of the obstacks in this objfile, |
| 333 | so that it gets freed automatically when reading a new object |
| 334 | file. */ |
| 335 | |
| 336 | PTR obj_private; |
| 337 | |
| 338 | /* Set of relocation offsets to apply to each section. |
| 339 | Currently on the psymbol_obstack (which makes no sense, but I'm |
| 340 | not sure it's harming anything). |
| 341 | |
| 342 | These offsets indicate that all symbols (including partial and |
| 343 | minimal symbols) which have been read have been relocated by this |
| 344 | much. Symbols which are yet to be read need to be relocated by |
| 345 | it. */ |
| 346 | |
| 347 | struct section_offsets *section_offsets; |
| 348 | int num_sections; |
| 349 | |
| 350 | /* set of section begin and end addresses used to map pc addresses |
| 351 | into sections. Currently on the psymbol_obstack (which makes no |
| 352 | sense, but I'm not sure it's harming anything). */ |
| 353 | |
| 354 | struct obj_section |
| 355 | *sections, |
| 356 | *sections_end; |
| 357 | |
| 358 | /* two auxiliary fields, used to hold the fp of separate symbol files */ |
| 359 | FILE *auxf1, *auxf2; |
| 360 | |
| 361 | /* Place to stash various statistics about this objfile */ |
| 362 | OBJSTATS; |
| 363 | }; |
| 364 | |
| 365 | /* Defines for the objfile flag word. */ |
| 366 | |
| 367 | /* Gdb can arrange to allocate storage for all objects related to a |
| 368 | particular objfile in a designated section of its address space, |
| 369 | managed at a low level by mmap() and using a special version of |
| 370 | malloc that handles malloc/free/realloc on top of the mmap() interface. |
| 371 | This allows the "internal gdb state" for a particular objfile to be |
| 372 | dumped to a gdb state file and subsequently reloaded at a later time. */ |
| 373 | |
| 374 | #define OBJF_MAPPED (1 << 0) /* Objfile data is mmap'd */ |
| 375 | |
| 376 | /* When using mapped/remapped predigested gdb symbol information, we need |
| 377 | a flag that indicates that we have previously done an initial symbol |
| 378 | table read from this particular objfile. We can't just look for the |
| 379 | absence of any of the three symbol tables (msymbols, psymtab, symtab) |
| 380 | because if the file has no symbols for example, none of these will |
| 381 | exist. */ |
| 382 | |
| 383 | #define OBJF_SYMS (1 << 1) /* Have tried to read symbols */ |
| 384 | |
| 385 | /* When an object file has its functions reordered (currently Irix-5.2 |
| 386 | shared libraries exhibit this behaviour), we will need an expensive |
| 387 | algorithm to locate a partial symtab or symtab via an address. |
| 388 | To avoid this penalty for normal object files, we use this flag, |
| 389 | whose setting is determined upon symbol table read in. */ |
| 390 | |
| 391 | #define OBJF_REORDERED (2 << 1) /* Functions are reordered */ |
| 392 | |
| 393 | /* The object file that the main symbol table was loaded from (e.g. the |
| 394 | argument to the "symbol-file" or "file" command). */ |
| 395 | |
| 396 | extern struct objfile *symfile_objfile; |
| 397 | |
| 398 | /* The object file that contains the runtime common minimal symbols |
| 399 | for SunOS4. Note that this objfile has no associated BFD. */ |
| 400 | |
| 401 | extern struct objfile *rt_common_objfile; |
| 402 | |
| 403 | /* When we need to allocate a new type, we need to know which type_obstack |
| 404 | to allocate the type on, since there is one for each objfile. The places |
| 405 | where types are allocated are deeply buried in function call hierarchies |
| 406 | which know nothing about objfiles, so rather than trying to pass a |
| 407 | particular objfile down to them, we just do an end run around them and |
| 408 | set current_objfile to be whatever objfile we expect to be using at the |
| 409 | time types are being allocated. For instance, when we start reading |
| 410 | symbols for a particular objfile, we set current_objfile to point to that |
| 411 | objfile, and when we are done, we set it back to NULL, to ensure that we |
| 412 | never put a type someplace other than where we are expecting to put it. |
| 413 | FIXME: Maybe we should review the entire type handling system and |
| 414 | see if there is a better way to avoid this problem. */ |
| 415 | |
| 416 | extern struct objfile *current_objfile; |
| 417 | |
| 418 | /* All known objfiles are kept in a linked list. This points to the |
| 419 | root of this list. */ |
| 420 | |
| 421 | extern struct objfile *object_files; |
| 422 | |
| 423 | /* Declarations for functions defined in objfiles.c */ |
| 424 | |
| 425 | extern struct objfile * |
| 426 | allocate_objfile PARAMS ((bfd *, int)); |
| 427 | |
| 428 | extern int |
| 429 | build_objfile_section_table PARAMS ((struct objfile *)); |
| 430 | |
| 431 | extern void objfile_to_front PARAMS ((struct objfile *)); |
| 432 | |
| 433 | extern void |
| 434 | unlink_objfile PARAMS ((struct objfile *)); |
| 435 | |
| 436 | extern void |
| 437 | free_objfile PARAMS ((struct objfile *)); |
| 438 | |
| 439 | extern void |
| 440 | free_all_objfiles PARAMS ((void)); |
| 441 | |
| 442 | extern void |
| 443 | objfile_relocate PARAMS ((struct objfile *, struct section_offsets *)); |
| 444 | |
| 445 | extern int |
| 446 | have_partial_symbols PARAMS ((void)); |
| 447 | |
| 448 | extern int |
| 449 | have_full_symbols PARAMS ((void)); |
| 450 | |
| 451 | /* Functions for dealing with the minimal symbol table, really a misc |
| 452 | address<->symbol mapping for things we don't have debug symbols for. */ |
| 453 | |
| 454 | extern int |
| 455 | have_minimal_symbols PARAMS ((void)); |
| 456 | |
| 457 | extern struct obj_section * |
| 458 | find_pc_section PARAMS((CORE_ADDR pc)); |
| 459 | |
| 460 | extern struct obj_section * |
| 461 | find_pc_sect_section PARAMS((CORE_ADDR pc, asection *section)); |
| 462 | |
| 463 | extern int |
| 464 | in_plt_section PARAMS ((CORE_ADDR, char *)); |
| 465 | |
| 466 | /* Traverse all object files. ALL_OBJFILES_SAFE works even if you delete |
| 467 | the objfile during the traversal. */ |
| 468 | |
| 469 | #define ALL_OBJFILES(obj) \ |
| 470 | for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next) |
| 471 | |
| 472 | #define ALL_OBJFILES_SAFE(obj,nxt) \ |
| 473 | for ((obj) = object_files; \ |
| 474 | (obj) != NULL? ((nxt)=(obj)->next,1) :0; \ |
| 475 | (obj) = (nxt)) |
| 476 | |
| 477 | /* Traverse all symtabs in one objfile. */ |
| 478 | |
| 479 | #define ALL_OBJFILE_SYMTABS(objfile, s) \ |
| 480 | for ((s) = (objfile) -> symtabs; (s) != NULL; (s) = (s) -> next) |
| 481 | |
| 482 | /* Traverse all psymtabs in one objfile. */ |
| 483 | |
| 484 | #define ALL_OBJFILE_PSYMTABS(objfile, p) \ |
| 485 | for ((p) = (objfile) -> psymtabs; (p) != NULL; (p) = (p) -> next) |
| 486 | |
| 487 | /* Traverse all minimal symbols in one objfile. */ |
| 488 | |
| 489 | #define ALL_OBJFILE_MSYMBOLS(objfile, m) \ |
| 490 | for ((m) = (objfile) -> msymbols; SYMBOL_NAME(m) != NULL; (m)++) |
| 491 | |
| 492 | /* Traverse all symtabs in all objfiles. */ |
| 493 | |
| 494 | #define ALL_SYMTABS(objfile, s) \ |
| 495 | ALL_OBJFILES (objfile) \ |
| 496 | ALL_OBJFILE_SYMTABS (objfile, s) |
| 497 | |
| 498 | /* Traverse all psymtabs in all objfiles. */ |
| 499 | |
| 500 | #define ALL_PSYMTABS(objfile, p) \ |
| 501 | ALL_OBJFILES (objfile) \ |
| 502 | ALL_OBJFILE_PSYMTABS (objfile, p) |
| 503 | |
| 504 | /* Traverse all minimal symbols in all objfiles. */ |
| 505 | |
| 506 | #define ALL_MSYMBOLS(objfile, m) \ |
| 507 | ALL_OBJFILES (objfile) \ |
| 508 | if ((objfile)->msymbols) \ |
| 509 | ALL_OBJFILE_MSYMBOLS (objfile, m) |
| 510 | |
| 511 | #define ALL_OBJFILE_OSECTIONS(objfile, osect) \ |
| 512 | for (osect = objfile->sections; osect < objfile->sections_end; osect++) |
| 513 | |
| 514 | #define ALL_OBJSECTIONS(objfile, osect) \ |
| 515 | ALL_OBJFILES (objfile) \ |
| 516 | ALL_OBJFILE_OSECTIONS (objfile, osect) |
| 517 | |
| 518 | #endif /* !defined (OBJFILES_H) */ |