1 ------------------------------------------------------------------------------
3 -- GNAT COMPILER COMPONENTS --
9 -- Copyright (C) 1992-2009, Free Software Foundation, Inc. --
11 -- GNAT is free software; you can redistribute it and/or modify it under --
12 -- terms of the GNU General Public License as published by the Free Soft- --
13 -- ware Foundation; either version 3, or (at your option) any later ver- --
14 -- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
15 -- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
16 -- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
17 -- for more details. You should have received a copy of the GNU General --
18 -- Public License distributed with GNAT; see file COPYING3. If not, go to --
19 -- http://www.gnu.org/licenses for a complete copy of the license. --
21 -- GNAT was originally developed by the GNAT team at New York University. --
22 -- Extensive contributions were provided by Ada Core Technologies Inc. --
24 ------------------------------------------------------------------------------
26 -- This package contains the routines for writing the library information
30 -----------------------------------
31 -- Format of Library Information --
32 -----------------------------------
34 -- This section describes the format of the library information that is
35 -- associated with object files. The exact method of this association is
36 -- potentially implementation dependent and is described and implemented in
37 -- package ali. From the point of view of the description here, all we need
38 -- to know is that the information is represented as a string of characters
39 -- that is somehow associated with an object file, and can be retrieved. If
40 -- no library information exists for a given object file, then we take this
41 -- as equivalent to the non-existence of the object file, as if source file
42 -- has not been previously compiled.
44 -- The library information is written as a series of lines of the form:
46 -- Key_Character parameter parameter ...
48 -- The following sections describe the format of these lines in detail
50 --------------------------------------
51 -- Making Changes to the ALI Format --
52 --------------------------------------
54 -- A number of tools use ali.adb to parse ali files. This means that
55 -- changes to this format can cause old versions of these tools to be
56 -- incompatible with new versions of the compiler. Any changes to ali file
57 -- formats must be carefully evaluated to understand any such possible
58 -- conflicts, and in particular, it is very undesirable to create conflicts
59 -- between older versions of GPS and newer versions of the compiler.
61 -- If the following guidelines are respected, downward compatibility
62 -- problems (old tools reading new ali files) should be minimized:
64 -- The basic key character format must be kept
66 -- The V line must be the first line, this is checked by ali.adb even in
67 -- Ignore_Errors mode, and is used to verify that the file at hand is
68 -- indeed likely intended to be an ali file.
70 -- The P line must be present, though may be modified in contents
71 -- according to remaining guidelines. Again, ali.adb assumes the P
72 -- line is present even in Ignore_Errors mode.
74 -- New modifiers can generally be added (in particular adding new two
75 -- letter modifiers to the P or U lines is always safe)
77 -- Adding entirely new lines (with a new key letter) to the ali file is
78 -- always safe, at any point (other than before the V line), since such
79 -- lines will be ignored.
81 -- Following the guidelines in this section should ensure that this problem
82 -- is minimized and that old tools will be able to deal successfully with
83 -- new ali formats. Note that this does not apply to the compiler itself,
84 -- which always requires consistency between the ali files and the binder.
85 -- That is because one of the main functions of the binder is to ensure
86 -- consistency of the partition, and this can be compromised if the ali
87 -- files are inconsistent.
93 -- The initial header lines in the file give information about the
94 -- compilation environment, and identify other special information such as
95 -- main program parameters.
101 -- V "xxxxxxxxxxxxxxxx"
103 -- This line indicates the library output version, as defined in
104 -- Gnatvsn. It ensures that separate object modules of a program are
105 -- consistent. It has to be changed if anything changes which would
106 -- affect successful binding of separately compiled modules. Examples
107 -- of such changes are modifications in the format of the library info
108 -- described in this package, or modifications to calling sequences, or
109 -- to the way that data is represented.
111 -- Note: the V line absolutely must be the first line, and no change
112 -- to the ALI format should change this, since even in Ignore_Errors
113 -- mode, Scan_ALI insists on finding a V line.
115 -- ---------------------
116 -- -- M Main Program --
117 -- ---------------------
119 -- M type [priority] [T=time-slice] W=?
121 -- This line appears only if the main unit for this file is suitable
122 -- for use as a main program. The parameters are:
126 -- P for a parameterless procedure
127 -- F for a function returning a value of integral type
128 -- (used for writing a main program returning an exit status)
132 -- Present only if there was a valid pragma Priority in the
133 -- corresponding unit to set the main task priority. It is an
134 -- unsigned decimal integer.
138 -- Present only if there was a valid pragma Time_Slice in the
139 -- corresponding unit. It is an unsigned decimal integer in the
140 -- range 0 .. 10**9 giving the time slice value in units of
141 -- milliseconds. The actual significance of this parameter is
146 -- This parameter indicates the wide character encoding method used
147 -- when compiling the main program file. The ? character is the
148 -- single character used in the -gnatW? switch. This is used to
149 -- provide the default wide-character encoding for Wide_Text_IO
158 -- One of these lines appears for each of the arguments present in the
159 -- call to the gnat1 program. This can be used if it is necessary to
160 -- reconstruct this call (e.g. for fix and continue)
162 -- -------------------
163 -- -- P Parameters --
164 -- -------------------
168 -- Indicates various information that applies to the compilation of the
169 -- corresponding source file. Parameters is a sequence of zero or more
170 -- two letter codes that indicate configuration pragmas and other
171 -- parameters that apply:
173 -- The arguments are as follows:
175 -- CE Compilation errors. If this is present it means that the ali
176 -- file resulted from a compilation with the -gnatQ switch set,
177 -- and illegalities were detected. The ali file contents may
178 -- not be completely reliable, but the format will be correct
179 -- and complete. Note that NO is always present if CE is
182 -- DB Detect_Blocking pragma is in effect for all units in this
185 -- FD Configuration pragmas apply to all the units in this file
186 -- specifying a possibly non-standard floating point format
187 -- (VAX float with Long_Float using D_Float).
189 -- FG Configuration pragmas apply to all the units in this file
190 -- specifying a possibly non-standard floating point format
191 -- (VAX float with Long_Float using G_Float).
193 -- FI Configuration pragmas apply to all the units in this file
194 -- specifying a possibly non-standard floating point format
197 -- Lx A valid Locking_Policy pragma applies to all the units in
198 -- this file, where x is the first character (upper case) of
199 -- the policy name (e.g. 'C' for Ceiling_Locking).
201 -- NO No object. This flag indicates that the units in this file
202 -- were not compiled to produce an object. This can occur as a
203 -- result of the use of -gnatc, or if no object can be produced
204 -- (e.g. when a package spec is compiled instead of the body,
205 -- or a subunit on its own).
207 -- NR No_Run_Time. Indicates that a pragma No_Run_Time applies
208 -- to all units in the file.
210 -- NS Normalize_Scalars pragma in effect for all units in
213 -- Qx A valid Queueing_Policy pragma applies to all the units
214 -- in this file, where x is the first character (upper case)
215 -- of the policy name (e.g. 'P' for Priority_Queueing).
217 -- SL Indicates that the unit is an Interface to a Standalone
218 -- Library. Note that this indication is never given by the
219 -- compiler, but is added by the Project Manager in gnatmake
220 -- when an Interface ALI file is copied to the library
223 -- SS This unit references System.Secondary_Stack (that is,
224 -- the unit makes use of the secondary stack facilities).
226 -- Tx A valid Task_Dispatching_Policy pragma applies to all
227 -- the units in this file, where x is the first character
228 -- (upper case) of the corresponding policy name (e.g. 'F'
229 -- for FIFO_Within_Priorities).
231 -- UA Unreserve_All_Interrupts pragma was processed in one or
232 -- more units in this file
234 -- ZX Units in this file use zero-cost exceptions and have
235 -- generated exception tables. If ZX is not present, the
236 -- longjmp/setjmp exception scheme is in use.
238 -- Note that language defined units never output policy (Lx,Tx,Qx)
239 -- parameters. Language defined units must correctly handle all
240 -- possible cases. These values are checked for consistency by the
241 -- binder and then copied to the generated binder output file.
243 -- Note: The P line must be present. Even in Ignore_Errors mode, Scan_ALI
244 -- insists on finding a P line. So if changes are made to the ALI format,
245 -- they should not include removing the P line!
247 -- ---------------------
248 -- -- R Restrictions --
249 -- ---------------------
251 -- The first R line records the status of restrictions generated by pragma
252 -- Restrictions encountered, as well as information on what the compiler
253 -- has been able to determine with respect to restrictions violations.
256 -- R <<restriction-characters>> <<restriction-param-id-entries>>
258 -- The first parameter is a string of characters that records
259 -- information regarding restrictions that do not take parameter not
260 -- take parameter values. It is a string of characters, one character
261 -- for each value (in order) in All_Boolean_Restrictions. There are
262 -- three possible settings for each restriction:
264 -- r Restricted. Unit was compiled under control of a pragma
265 -- Restrictions for the corresponding restriction. In this case
266 -- the unit certainly does not violate the Restriction, since
267 -- this would have been detected by the compiler.
269 -- n Not used. The unit was not compiled under control of a pragma
270 -- Restrictions for the corresponding restriction, and does not
271 -- make any use of the referenced feature.
273 -- v Violated. The unit was not compiled under control of a pragma
274 -- Restrictions for the corresponding restriction, and it does
275 -- indeed use the referenced feature.
277 -- This information is used in the binder to check consistency, i.e. to
278 -- detect cases where one unit has "r" and another unit has "v", which
279 -- is not permitted, since these restrictions are partition-wide.
281 -- The second parameter, which immediately follows the first (with no
282 -- separating space) gives restriction information for identifiers for
283 -- which a parameter is given.
285 -- The parameter is a string of entries, one for each value in
286 -- Restrict.All_Parameter_Restrictions. Each entry has two components
287 -- in sequence, the first indicating whether or not there is a
288 -- restriction, and the second indicating whether or not the compiler
289 -- detected violations. In the boolean case it is not necessary to
290 -- separate these, since if a restriction is set, and violated, that is
291 -- an error. But in the parameter case, this is not true. For example,
292 -- we can have a unit with a pragma Restrictions (Max_Tasks => 4),
293 -- where the compiler can detect that there are exactly three tasks
294 -- declared. Both of these pieces of information must be passed to the
295 -- binder. The parameter of 4 is important in case the total number of
296 -- tasks in the partition is greater than 4. The parameter of 3 is
297 -- important in case some other unit has a restrictions pragma with
300 -- The component for the presence of restriction has one of two
303 -- n No pragma for this restriction is present in the set of units
304 -- for this ali file.
306 -- rN At least one pragma for this restriction is present in the
307 -- set of units for this ali file. The value N is the minimum
308 -- parameter value encountered in any such pragma. N is in the
309 -- range of Integer (a value larger than N'Last causes the
310 -- pragma to be ignored).
312 -- The component for the violation detection has one of three
315 -- n No violations were detected by the compiler
317 -- vN A violation was detected. N is either the maximum or total
318 -- count of violations (depending on the checking type) in all
319 -- the units represented by the ali file). Note that this
320 -- setting is only allowed for restrictions that are in
321 -- Checked_[Max|Sum]_Parameter_Restrictions. The value here is
322 -- known to be exact by the compiler and is in the range of
325 -- vN+ A violation was detected. The compiler cannot determine
326 -- the exact count of violations, but it is at least N.
328 -- There are no spaces within the parameter string, so the entry
329 -- described above in the header of this section for Max_Tasks would
330 -- appear as the string r4v3.
332 -- Note: The restrictions line is required to be present. Even in
333 -- Ignore_Errors mode, Scan_ALI expects to find an R line and will
334 -- signal a fatal error if it is missing. This means that future
335 -- changes to the ALI file format must retain the R line.
337 -- Subsequent R lines are present only if pragma Restriction No_Dependence
338 -- is used. There is one such line for each such pragma appearing in the
339 -- extended main unit. The format is
343 -- Here the unit name is in all lower case. The components of the unit
344 -- name are separated by periods. The names themselves are in encoded
345 -- form, as documented in Namet.
347 -- -------------------------
348 -- -- I Interrupt States --
349 -- -------------------------
351 -- I interrupt-number interrupt-state line-number
353 -- This line records information from an Interrupt_State pragma. There
354 -- is one line for each separate pragma, and if no such pragmas are
355 -- used, then no I lines are present.
357 -- The interrupt-number is an unsigned positive integer giving the
358 -- value of the interrupt as defined in Ada.Interrupts.Names.
360 -- The interrupt-state is one of r/s/u for Runtime/System/User
362 -- The line number is an unsigned decimal integer giving the line
363 -- number of the corresponding Interrupt_State pragma. This is used
364 -- in consistency messages.
366 -- --------------------------------------
367 -- -- S Priority Specific Dispatching --
368 -- --------------------------------------
370 -- S policy_identifier first_priority last_priority line-number
372 -- This line records information from a Priority_Specific_Dispatching
373 -- pragma. There is one line for each separate pragma, and if no such
374 -- pragmas are used, then no S lines are present.
376 -- The policy_identifier is the first character (upper case) of the
377 -- corresponding policy name (e.g. 'F' for FIFO_Within_Priorities).
379 -- The first_priority and last_priority fields define the range of
380 -- priorities to which the specified dispatching policy apply.
382 -- The line number is an unsigned decimal integer giving the line
383 -- number of the corresponding Priority_Specific_Dispatching pragma.
384 -- This is used in consistency messages.
386 ----------------------------
387 -- Compilation Unit Lines --
388 ----------------------------
390 -- Following these header lines, a set of information lines appears for
391 -- each compilation unit that appears in the corresponding object file. In
392 -- particular, when a package body or subprogram body is compiled, there
393 -- will be two sets of information, one for the spec and one for the body,
394 -- with the entry for the body appearing first. This is the only case in
395 -- which a single ALI file contains more than one unit (in particular note
396 -- that subunits do *not* count as compilation units for this purpose, and
397 -- generate no library information, since they are inlined).
399 -- --------------------
400 -- -- U Unit Header --
401 -- --------------------
403 -- The lines for each compilation unit have the following form
405 -- U unit-name source-name version <<attributes>>
407 -- This line identifies the unit to which this section of the library
408 -- information file applies. The first three parameters are the unit
409 -- name in internal format, as described in package Uname, and the name
410 -- of the source file containing the unit.
412 -- Version is the version given as eight hexadecimal characters with
413 -- upper case letters. This value is the exclusive or of the source
414 -- checksums of the unit and all its semantically dependent units.
416 -- The <<attributes>> are a series of two letter codes indicating
417 -- information about the unit:
419 -- BD Unit does not have pragma Elaborate_Body, but the elaboration
420 -- circuit has determined that it would be a good idea if this
421 -- pragma were present, since the body of the package contains
422 -- elaboration code that modifies one or more variables in the
423 -- visible part of the package. The binder will try, but does
424 -- not promise, to keep the elaboration of the body close to
425 -- the elaboration of the spec.
427 -- DE Dynamic Elaboration. This unit was compiled with the dynamic
428 -- elaboration model, as set by either the -gnatE switch or
429 -- pragma Elaboration_Checks (Dynamic).
431 -- EB Unit has pragma Elaborate_Body, or is a generic instance that
432 -- has a body. Set for instances because RM 12.3(20) requires
433 -- that the body be immediately elaborated after the spec (we
434 -- would normally do that anyway, because elaborate spec and
435 -- body together whenever possible, and for an instance it is
436 -- always possible; however setting EB ensures that this is done
437 -- even when using the -p gnatbind switch).
439 -- EE Elaboration entity is present which must be set true when
440 -- the unit is elaborated. The name of the elaboration entity is
441 -- formed from the unit name in the usual way. If EE is present,
442 -- then this boolean must be set True as part of the elaboration
443 -- processing routine generated by the binder. Note that EE can
444 -- be set even if NE is set. This happens when the boolean is
445 -- needed solely for checking for the case of access before
448 -- GE Unit is a generic declaration, or corresponding body
450 -- IL Unit source uses a style with identifiers in all lower-case
451 -- IU (IL) or all upper case (IU). If the standard mixed-case usage
452 -- is detected, or the compiler cannot determine the style, then
453 -- no I parameter will appear.
455 -- IS Initialize_Scalars pragma applies to this unit, or else there
456 -- is at least one use of the Invalid_Value attribute.
458 -- KM Unit source uses a style with keywords in mixed case (KM)
459 -- KU or all upper case (KU). If the standard lower-case usage is
460 -- is detected, or the compiler cannot determine the style, then
461 -- no K parameter will appear.
463 -- NE Unit has no elaboration routine. All subprogram bodies and
464 -- specs are in this category. Package bodies and specs may or
465 -- may not have NE set, depending on whether or not elaboration
466 -- code is required. Set if N_Compilation_Unit node has flag
467 -- Has_No_Elaboration_Code set.
469 -- OL The units in this file are compiled with a local pragma
470 -- Optimize_Alignment, so no consistency requirement applies
471 -- to these units. All internal units have this status since
472 -- they have an automatic default of Optimize_Alignment (Off).
474 -- OO Optimize_Alignment (Off) is the default setting for all
475 -- units in this file. All files in the partition that specify
476 -- a default must specify the same default.
478 -- OS Optimize_Alignment (Space) is the default setting for all
479 -- units in this file. All files in the partition that specify
480 -- a default must specify the same default.
482 -- OT Optimize_Alignment (Time) is the default setting for all
483 -- units in this file. All files in the partition that specify
484 -- a default must specify the same default.
486 -- PK Unit is package, rather than a subprogram
488 -- PU Unit has pragma Pure
490 -- PR Unit has pragma Preelaborate
492 -- RA Unit declares a Remote Access to Class-Wide (RACW) type
494 -- RC Unit has pragma Remote_Call_Interface
496 -- RT Unit has pragma Remote_Types
498 -- SP Unit has pragma Shared_Passive.
500 -- SU Unit is a subprogram, rather than a package
502 -- The attributes may appear in any order, separated by spaces.
504 -- ---------------------
505 -- -- W Withed Units --
506 -- ---------------------
508 -- Following each U line, is a series of lines of the form
510 -- W unit-name [source-name lib-name] [E] [EA] [ED] [AD]
512 -- One of these lines is present for each unit that is mentioned in an
513 -- explicit with clause by the current unit. The first parameter is the
514 -- unit name in internal format. The second parameter is the file name
515 -- of the file that must be compiled to compile this unit. It is
516 -- usually the file for the body, except for packages which have no
517 -- body. For units that need a body, if the source file for the body
518 -- cannot be found, the file name of the spec is used instead. The
519 -- third parameter is the file name of the library information file
520 -- that contains the results of compiling this unit. The optional
521 -- modifiers are used as follows:
523 -- E pragma Elaborate applies to this unit
525 -- EA pragma Elaborate_All applies to this unit
527 -- ED Elaborate_Desirable set for this unit, which means that there
528 -- is no Elaborate, but the analysis suggests that Program_Error
529 -- may be raised if the Elaborate conditions cannot be satisfied.
530 -- The binder will attempt to treat ED as E if it can.
532 -- AD Elaborate_All_Desirable set for this unit, which means that
533 -- there is no Elaborate_All, but the analysis suggests that
534 -- Program_Error may be raised if the Elaborate_All conditions
535 -- cannot be satisfied. The binder will attempt to treat AD as
538 -- The parameter source-name and lib-name are omitted for the case of a
539 -- generic unit compiled with earlier versions of GNAT which did not
540 -- generate object or ali files for generics.
542 -- In fact W lines include implicit withs ???
544 -- -----------------------
545 -- -- L Linker_Options --
546 -- -----------------------
548 -- Following the W lines (if any, or the U line if not), are an optional
549 -- series of lines that indicates the usage of the pragma Linker_Options in
550 -- the associated unit. For each appearance of a pragma Linker_Options (or
551 -- Link_With) in the unit, a line is present with the form:
555 -- where string is the string from the unit line enclosed in quotes.
556 -- Within the quotes the following can occur:
558 -- c graphic characters in range 20-7E other than " or {
559 -- "" indicating a single " character
560 -- {hh} indicating a character whose code is hex hh (0-9,A-F)
561 -- {00} [ASCII.NUL] is used as a separator character
562 -- to separate multiple arguments of a single
563 -- Linker_Options pragma.
565 -- For further details, see Stringt.Write_String_Table_Entry. Note that
566 -- wide characters in the form {hhhh} cannot be produced, since pragma
567 -- Linker_Option accepts only String, not Wide_String.
569 -- The L lines are required to appear in the same order as the
570 -- corresponding Linker_Options (or Link_With) pragmas appear in the
571 -- source file, so that this order is preserved by the binder in
572 -- constructing the set of linker arguments.
574 ---------------------
575 -- Reference Lines --
576 ---------------------
578 -- The reference lines contain information about references from any of the
579 -- units in the compilation (including, body version and version
580 -- attributes, linker options pragmas and source dependencies.
582 -- ------------------------------------
583 -- -- E External Version References --
584 -- ------------------------------------
586 -- One of these lines is present for each use of 'Body_Version or 'Version
587 -- in any of the units of the compilation. These are used by the linker to
588 -- determine which version symbols must be output. The format is simply:
592 -- where name is the external name, i.e. the unit name with either a S or a
593 -- B for spec or body version referenced (Body_Version always references
594 -- the body, Version references the Spec, except in the case of a reference
595 -- to a subprogram with no separate spec). Upper half and wide character
596 -- codes are encoded using the same method as in Namet (Uhh for upper half,
597 -- Whhhh for wide character, where hh are hex digits).
599 -- ---------------------
600 -- -- D Dependencies --
601 -- ---------------------
603 -- The dependency lines indicate the source files on which the compiled
604 -- units depend. This is used by the binder for consistency checking.
605 -- These lines are also referenced by the cross-reference information.
607 -- D source-name time-stamp checksum [subunit-name] line:file-name
609 -- The time-stamp field contains the time stamp of the corresponding
610 -- source file. See types.ads for details on time stamp representation.
612 -- The checksum is an 8-hex digit representation of the source file
613 -- checksum, with letters given in lower case.
615 -- The subunit name is present only if the dependency line is for a
616 -- subunit. It contains the fully qualified name of the subunit in all
617 -- lower case letters.
619 -- The line:file-name entry is present only if a Source_Reference
620 -- pragma appeared in the source file identified by source-name. In
621 -- this case, it gives the information from this pragma. Note that this
622 -- allows cross-reference information to be related back to the
623 -- original file. Note: the reason the line number comes first is that
624 -- a leading digit immediately identifies this as a Source_Reference
625 -- entry, rather than a subunit-name.
627 -- A line number of zero for line: in this entry indicates that there
628 -- is more than one source reference pragma. In this case, the line
629 -- numbers in the cross-reference are correct, and refer to the
630 -- original line number, but there is no information that allows a
631 -- reader of the ALI file to determine the exact mapping of physical
632 -- line numbers back to the original source.
634 -- Files with a zero checksum and a non-zero time stamp are in general
635 -- files on which the compilation depends but which are not Ada files
636 -- with further dependencies. This includes preprocessor data files
637 -- and preprocessor definition files.
639 -- Note: blank lines are ignored when the library information is read,
640 -- and separate sections of the file are separated by blank lines to
641 -- ease readability. Blanks between fields are also ignored.
643 -- For entries corresponding to files that were not present (and thus
644 -- resulted in error messages), or for files that are not part of the
645 -- dependency set, both the time stamp and checksum are set to all zero
646 -- characters. These dummy entries are ignored by the binder in
647 -- dependency checking, but must be present for proper interpretation
648 -- of the cross-reference data.
650 --------------------------
651 -- Cross-Reference Data --
652 --------------------------
654 -- The cross-reference data follows the dependency lines. See the spec of
655 -- Lib.Xref for details on the format of this data.
657 ---------------------------------
658 -- Source Coverage Obligations --
659 ---------------------------------
661 -- The Source Coverage Obligation (SCO) information follows the cross-
662 -- reference data. See the spec of Par_SCO for full details of the format.
664 ----------------------
665 -- Global_Variables --
666 ----------------------
668 -- The table structure defined here stores one entry for each
669 -- Interrupt_State pragma encountered either in the main source or
670 -- in an ancillary with'ed source. Since interrupt state values
671 -- have to be consistent across all units in a partition, we may
672 -- as well detect inconsistencies at compile time when we can.
674 type Interrupt_State_Entry
is record
675 Interrupt_Number
: Pos
;
676 -- Interrupt number value
678 Interrupt_State
: Character;
679 -- Set to r/s/u for Runtime/System/User
681 Pragma_Loc
: Source_Ptr
;
682 -- Location of pragma setting this value in place
685 package Interrupt_States
is new Table
.Table
(
686 Table_Component_Type
=> Interrupt_State_Entry
,
687 Table_Index_Type
=> Nat
,
688 Table_Low_Bound
=> 1,
690 Table_Increment
=> 200,
691 Table_Name
=> "Name_Interrupt_States");
693 -- The table structure defined here stores one entry for each
694 -- Priority_Specific_Dispatching pragma encountered either in the main
695 -- source or in an ancillary with'ed source. Since have to be consistent
696 -- across all units in a partition, we may as well detect inconsistencies
697 -- at compile time when we can.
699 type Specific_Dispatching_Entry
is record
700 Dispatching_Policy
: Character;
701 -- First character (upper case) of the corresponding policy name
703 First_Priority
: Nat
;
704 -- Lower bound of the priority range to which the specified dispatching
708 -- Upper bound of the priority range to which the specified dispatching
711 Pragma_Loc
: Source_Ptr
;
712 -- Location of pragma setting this value in place
715 package Specific_Dispatching
is new Table
.Table
(
716 Table_Component_Type
=> Specific_Dispatching_Entry
,
717 Table_Index_Type
=> Nat
,
718 Table_Low_Bound
=> 1,
720 Table_Increment
=> 100,
721 Table_Name
=> "Name_Priority_Specific_Dispatching");
727 procedure Ensure_System_Dependency
;
728 -- This procedure ensures that a dependency is created on system.ads. Even
729 -- if there is no semantic dependency, Targparm has read the file to
730 -- acquire target parameters, so we need a source dependency.
732 procedure Write_ALI
(Object
: Boolean);
733 -- This procedure writes the library information for the current main unit
734 -- The Object parameter is true if an object file is created, and false
737 -- Note: in the case where we are not generating code (-gnatc mode), this
738 -- routine only writes an ALI file if it cannot find an existing up to
739 -- date ALI file. If it *can* find an existing up to date ALI file, then
740 -- it reads this file and sets the Lib.Compilation_Arguments table from
741 -- the A lines in this file.
743 procedure Add_Preprocessing_Dependency
(S
: Source_File_Index
);
744 -- Indicate that there is a dependency to be added on a preprocessing data
745 -- file or on a preprocessing definition file.