1 ------------------------------------------------------------------------------
3 -- GNAT COMPILER COMPONENTS --
9 -- Copyright (C) 1992-2007, 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
37 -- in package ali. From the point of view of the description here, all we
38 -- need to know is that the information is represented as a string of
39 -- characters that is somehow associated with an object file, and can be
40 -- retrieved. If no library information exists for a given object file,
41 -- then we take this as equivalent to the non-existence of the object
42 -- file, as if source file 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
55 -- that changes to this format can cause old versions of these tools
56 -- to be incompatible with new versions of the compiler. Any changes
57 -- to ali file formats must be carefully evaluated to understand any
58 -- such possible conflicts, and in particular, it is very undesirable
59 -- to create conflicts between older versions of GPS and newer versions
62 -- If the following guidelines are respected, downward compatibility
63 -- problems (old tools reading new ali files) should be minimized:
65 -- The basic key character format must be kept
67 -- The V line must be the first line, this is checked by ali.adb
68 -- even in Ignore_Errors mode, and is used to verify that the file
69 -- at hand is indeed likely intended to be an ali file.
71 -- The P line must be present, though may be modified in contents
72 -- according to remaining guidelines. Again, ali.adb assumes the
73 -- P line is present even in Ignore_Errors mode.
75 -- New modifiers can generally be added (in particular adding new
76 -- two letter modifiers to the P or U lines is always safe)
78 -- Adding entirely new lines (with a new key letter) to the ali
79 -- file is always safe, at any point (other than before the V
80 -- line), since suchy lines will be ignored.
82 -- Following the guidelines in this section should ensure that this
83 -- problem is minimized and that old tools will be able to deal
84 -- successfully with new ali formats. Note that this does not apply
85 -- to the compiler itself, which always requires consistency between
86 -- the ali files and the binder. That is because one of the main
87 -- functions of the binder is to ensure consistency of the partition,
88 -- and this can be compromised if the ali files are inconsistent.
94 -- The initial header lines in the file give information about the
95 -- compilation environment, and identify other special information
96 -- such as main program parameters.
102 -- V "xxxxxxxxxxxxxxxx"
104 -- This line indicates the library output version, as defined in
105 -- Gnatvsn. It ensures that separate object modules of a program are
106 -- consistent. It has to be changed if anything changes which would
107 -- affect successful binding of separately compiled modules.
108 -- Examples of such changes are modifications in the format of the
109 -- library info described in this package, or modifications to
110 -- calling sequences, or to the way that data is represented.
112 -- Note: the V line absolutely must be the first line, and no change
113 -- to the ALI format should change this, since even in Ignore_Errors
114 -- mode, Scan_ALI insists on finding a V line.
116 -- ---------------------
117 -- -- M Main Program --
118 -- ---------------------
120 -- M type [priority] [T=time-slice] W=?
122 -- This line appears only if the main unit for this file is
123 -- suitable for use as a main program. The parameters are:
127 -- P for a parameterless procedure
128 -- F for a function returning a value of integral type
129 -- (used for writing a main program returning an exit status)
133 -- Present only if there was a valid pragma Priority in the
134 -- corresponding unit to set the main task priority. It is
135 -- an unsigned decimal integer.
139 -- Present only if there was a valid pragma Time_Slice in the
140 -- corresponding unit. It is an unsigned decimal integer in
141 -- the range 0 .. 10**9 giving the time slice value in units
142 -- of milliseconds. The actual significance of this parameter
143 -- is target dependent.
147 -- This parameter indicates the wide character encoding
148 -- method used when compiling the main program file. The ?
149 -- character is the single character used in the -gnatW?
150 -- switch. This is used to provide the default wide-character
151 -- encoding for Wide_Text_IO files.
159 -- One of these lines appears for each of the arguments present
160 -- in the call to the gnat1 program. This can be used if it is
161 -- necessary to reconstruct this call (e.g. for fix and continue)
163 -- -------------------
164 -- -- P Parameters --
165 -- -------------------
169 -- Indicates various information that applies to the compilation
170 -- of the corresponding source unit. Parameters is a sequence of
171 -- zero or more two letter codes that indicate configuration
172 -- pragmas and other parameters that apply:
174 -- The arguments are as follows:
176 -- CE Compilation errors. If this is present it means that the
177 -- ali file resulted from a compilation with the -gnatQ
178 -- switch set, and illegalities were detected. The ali
179 -- file contents may not be completely reliable, but the
180 -- format will be correct and complete. Note that NO is
181 -- always present if CE is present.
183 -- DB Detect_Blocking pragma is in effect for all units in
186 -- FD Configuration pragmas apply to all the units in this
187 -- file specifying a possibly non-standard floating point
188 -- format (VAX float with Long_Float using D_Float)
190 -- FG Configuration pragmas apply to all the units in this
191 -- file specifying a possibly non-standard floating point
192 -- format (VAX float with Long_Float using G_Float)
194 -- FI Configuration pragmas apply to all the units in this
195 -- file specifying a possibly non-standard floating point
196 -- format (IEEE Float)
198 -- Lx A valid Locking_Policy pragma applies to all the units
199 -- in this file, where x is the first character (upper case)
200 -- of the policy name (e.g. 'C' for Ceiling_Locking)
202 -- NO No object. This flag indicates that the units in this
203 -- file were not compiled to produce an object. This can
204 -- occur as a result of the use of -gnatc, or if no object
205 -- can be produced (e.g. when a package spec is compiled
206 -- instead of the body, or a subunit on its own).
208 -- NR No_Run_Time. Indicates that a pragma No_Run_Time applies
209 -- to all units in the file.
211 -- NS Normalize_Scalars pragma in effect for all units in
214 -- OS Optimize_Alignment (Space) active for all units in this file
216 -- OT Optimize_Alignment (Time) active for all units in this file
218 -- Qx A valid Queueing_Policy pragma applies to all the units
219 -- in this file, where x is the first character (upper case)
220 -- of the policy name (e.g. 'P' for Priority_Queueing).
222 -- SL Indicates that the unit is an Interface to a Standalone
223 -- Library. Note that this indication is never given by the
224 -- compiler, but is added by the Project Manager in gnatmake
225 -- when an Interface ALI file is copied to the library
228 -- SS This unit references System.Secondary_Stack (that is,
229 -- the unit makes use of the secondary stack facilities).
231 -- Tx A valid Task_Dispatching_Policy pragma applies to all
232 -- the units in this file, where x is the first character
233 -- (upper case) of the corresponding policy name (e.g. 'F'
234 -- for FIFO_Within_Priorities).
236 -- UA Unreserve_All_Interrupts pragma was processed in one or
237 -- more units in this file
239 -- ZX Units in this file use zero-cost exceptions and have
240 -- generated exception tables. If ZX is not present, the
241 -- longjmp/setjmp exception scheme is in use.
243 -- Note that language defined units never output policy (Lx,Tx,Qx)
244 -- parameters. Language defined units must correctly handle all
245 -- possible cases. These values are checked for consistency by the
246 -- binder and then copied to the generated binder output file.
248 -- Note: The P line must be present. Even in Ignore_Errors mode,
249 -- Scan_ALI insists on finding a P line. So if changes are made to
250 -- the ALI format, they should not include removing the P line!
252 -- ---------------------
253 -- -- R Restrictions --
254 -- ---------------------
256 -- The first R line records the status of restrictions generated by pragma
257 -- Restrictions encountered, as well as information on what the compiler
258 -- has been able to determine with respect to restrictions violations.
261 -- R <<restriction-characters>> <<restriction-param-id-entries>>
263 -- The first parameter is a string of characters that records
264 -- information regarding restrictions that do not take parameter
265 -- not take parameter values. It is a string of characters, one
266 -- character for each value (in order) in All_Boolean_Restrictions.
267 -- There are three possible settings for each restriction:
269 -- r Restricted. Unit was compiled under control of a pragma
270 -- Restrictions for the corresponding restriction. In
271 -- this case the unit certainly does not violate the
272 -- Restriction, since this would have been detected by
275 -- n Not used. The unit was not compiled under control of a
276 -- pragma Restrictions for the corresponding restriction,
277 -- and does not make any use of the referenced feature.
279 -- v Violated. The unit was not compiled under control of a
280 -- pragma Restrictions for the corresponding restriction,
281 -- and it does indeed use the referenced feature.
283 -- This information is used in the binder to check consistency,
284 -- i.e. to detect cases where one unit has "r" and another unit
285 -- has "v", which is not permitted, since these restrictions
286 -- are partition-wide.
288 -- The second parameter, which immediately follows the first (with
289 -- no separating space) gives restriction information for identifiers
290 -- for which a parameter is given.
292 -- The parameter is a string of entries, one for each value in
293 -- Restrict.All_Parameter_Restrictions. Each entry has two
294 -- components in sequence, the first indicating whether or not
295 -- there is a restriction, and the second indicating whether
296 -- or not the compiler detected violations. In the boolean case
297 -- it is not necessary to separate these, since if a restriction
298 -- is set, and violated, that is an error. But in the parameter
299 -- case, this is not true. For example, we can have a unit with
300 -- a pragma Restrictions (Max_Tasks => 4), where the compiler
301 -- can detect that there are exactly three tasks declared. Both
302 -- of these pieces of information must be passed to the binder.
303 -- The parameter of 4 is important in case the total number of
304 -- tasks in the partition is greater than 4. The parameter of
305 -- 3 is important in case some other unit has a restrictions
306 -- pragma with Max_Tasks=>2.
308 -- The component for the presence of restriction has one of two
311 -- n No pragma for this restriction is present in the
312 -- set of units for this ali file.
314 -- rN At least one pragma for this restriction is present
315 -- in the set of units for this ali file. The value N
316 -- is the minimum parameter value encountered in any
317 -- such pragma. N is in the range of Integer (a value
318 -- larger than N'Last causes the pragma to be ignored).
320 -- The component for the violation detection has one of three
323 -- n No violations were detected by the compiler
325 -- vN A violation was detected. N is either the maximum or total
326 -- count of violations (depending on the checking type) in
327 -- all the units represented by the ali file). Note that
328 -- this setting is only allowed for restrictions that are
329 -- in Checked_[Max|Sum]_Parameter_Restrictions. The value
330 -- here is known to be exact by the compiler and is in the
333 -- vN+ A violation was detected. The compiler cannot determine
334 -- the exact count of violations, but it is at least N.
336 -- There are no spaces within the parameter string, so the entry
337 -- described above in the header of this section for Max_Tasks would
338 -- appear as the string r4v3.
340 -- Note: The restrictions line is required to be present. Even in
341 -- Ignore_Errors mode, Scan_ALI expects to find an R line and will
342 -- signal a fatal error if it is missing. This means that future
343 -- changes to the ALI file format must retain the R line.
345 -- Subsequent R lines are present only if pragma Restriction No_Dependence
346 -- is used. There is one such line for each such pragma appearing in the
347 -- extended main unit. The format is
351 -- Here the unit name is in all lower case. The components of the unit
352 -- name are separated by periods. The names themselves are in encoded
353 -- form, as documented in Namet.
355 -- ------------------------
356 -- -- I Interrupt States --
357 -- ------------------------
359 -- I interrupt-number interrupt-state line-number
361 -- This line records information from an Interrupt_State pragma.
362 -- There is one line for each separate pragma, and if no such
363 -- pragmas are used, then no I lines are present.
365 -- The interrupt-number is an unsigned positive integer giving
366 -- the value of the interrupt as defined in Ada.Interrupts.Names.
368 -- The interrupt-state is one of r/s/u for Runtime/System/User
370 -- The line number is an unsigned decimal integer giving the
371 -- line number of the corresponding Interrupt_State pragma.
372 -- This is used in consistency messages.
374 -- -------------------------------------
375 -- -- S Priority Specific Dispatching --
376 -- -------------------------------------
378 -- S policy_identifier first_priority last_priority line-number
380 -- This line records information from a Priority_Specific_Dispatching
381 -- pragma. There is one line for each separate pragma, and if no such
382 -- pragmas are used, then no S lines are present.
384 -- The policy_identifier is the first character (upper case) of the
385 -- corresponding policy name (e.g. 'F' for FIFO_Within_Priorities).
387 -- The first_priority and last_priority fields define the range of
388 -- priorities to which the specified dispatching policy apply.
390 -- The line number is an unsigned decimal integer giving the
391 -- line number of the corresponding Priority_Specific_Dispatching
392 -- pragma. This is used in consistency messages.
394 ----------------------------
395 -- Compilation Unit Lines --
396 ----------------------------
398 -- Following these header lines, a set of information lines appears for
399 -- each compilation unit that appears in the corresponding object file.
400 -- In particular, when a package body or subprogram body is compiled,
401 -- there will be two sets of information, one for the spec and one for
402 -- the body. with the entry for the body appearing first. This is the
403 -- only case in which a single ALI file contains more than one unit (in
404 -- particular note that subunits do *not* count as compilation units for
405 -- this purpose, and generate no library information, since they are
408 -- --------------------
409 -- -- U Unit Header --
410 -- --------------------
412 -- The lines for each compilation unit have the following form
414 -- U unit-name source-name version <<attributes>>
416 -- This line identifies the unit to which this section of the
417 -- library information file applies. The first three parameters are
418 -- the unit name in internal format, as described in package Uname,
419 -- and the name of the source file containing the unit.
421 -- Version is the version given as eight hexadecimal characters
422 -- with upper case letters. This value is the exclusive or of the
423 -- source checksums of the unit and all its semantically dependent
426 -- The <<attributes>> are a series of two letter codes indicating
427 -- information about the unit:
429 -- BD Unit does not have pragma Elaborate_Body, but the elaboration
430 -- circuit has determined that it would be a good idea if this
431 -- pragma were present, since the body of the package contains
432 -- elaboration code that modifies one or more variables in the
433 -- visible part of the package. The binder will try, but does
434 -- not promise, to keep the elaboration of the body close to
435 -- the elaboration of the spec.
437 -- DE Dynamic Elaboration. This unit was compiled with the
438 -- dynamic elaboration model, as set by either the -gnatE
439 -- switch or pragma Elaboration_Checks (Dynamic).
441 -- EB Unit has pragma Elaborate_Body, or is a generic instance
442 -- that has a body. Set for instances because RM 12.3(20)
443 -- requires that the body be immediately elaborated after the
444 -- spec (we would normally do that anyway, because elaborate
445 -- spec and body together whenever possible, and for an instance
446 -- it is always possible; however setting EB ensures that this
447 -- is done even when using the -p gnatbind switch).
449 -- EE Elaboration entity is present which must be set true when
450 -- the unit is elaborated. The name of the elaboration entity
451 -- is formed from the unit name in the usual way. If EE is
452 -- present, then this boolean must be set True as part of the
453 -- elaboration processing routine generated by the binder.
454 -- Note that EE can be set even if NE is set. This happens
455 -- when the boolean is needed solely for checking for the
456 -- case of access before elaboration.
458 -- GE Unit is a generic declaration, or corresponding body
460 -- IL Unit source uses a style with identifiers in all lower
461 -- IU case (IL) or all upper case (IU). If the standard mixed-
462 -- case usage is detected, or the compiler cannot determine
463 -- the style, then no I parameter will appear.
465 -- IS Initialize_Scalars pragma applies to this unit
467 -- KM Unit source uses a style with keywords in mixed case
468 -- KU (KM) or all upper case (KU). If the standard lower-case
469 -- usage is detected, or the compiler cannot determine the
470 -- style, then no K parameter will appear.
472 -- NE Unit has no elaboration routine. All subprogram bodies
473 -- and specs are in this category. Package bodies and specs
474 -- may or may not have NE set, depending on whether or not
475 -- elaboration code is required. Set if N_Compilation_Unit
476 -- node has flag Has_No_Elaboration_Code set.
478 -- PK Unit is package, rather than a subprogram
480 -- PU Unit has pragma Pure
482 -- PR Unit has pragma Preelaborate
484 -- RA Unit declares a Remote Access to Class-Wide (RACW) type
486 -- RC Unit has pragma Remote_Call_Interface
488 -- RT Unit has pragma Remote_Types
490 -- SP Unit has pragma Shared_Passive.
492 -- SU Unit is a subprogram, rather than a package
494 -- The attributes may appear in any order, separated by spaces.
496 -- ---------------------
497 -- -- W Withed Units --
498 -- ---------------------
500 -- Following each U line, is a series of lines of the form
502 -- W unit-name [source-name lib-name] [E] [EA] [ED] [AD]
504 -- One of these lines is present for each unit that is mentioned in
505 -- an explicit with clause by the current unit. The first parameter is
506 -- the unit name in internal format. The second parameter is the file
507 -- name of the file that must be compiled to compile this unit. It is
508 -- usually the file for the body, except for packages which have no
509 -- body. For units that need a body, if the source file for the body
510 -- cannot be found, the file name of the spec is used instead. The
511 -- third parameter is the file name of the library information file
512 -- that contains the results of compiling this unit. The optional
513 -- modifiers are used as follows:
515 -- E pragma Elaborate applies to this unit
517 -- EA pragma Elaborate_All applies to this unit
519 -- ED Elaborate_Desirable set for this unit, which means
520 -- that there is no Elaborate, but the analysis suggests
521 -- that Program_Error may be raised if the Elaborate
522 -- conditions cannot be satisfied. The binder will attempt
523 -- to treat ED as E if it can.
525 -- AD Elaborate_All_Desirable set for this unit, which means
526 -- that there is no Elaborate_All, but the analysis suggests
527 -- that Program_Error may be raised if the Elaborate_All
528 -- conditions cannot be satisfied. The binder will attempt
529 -- to treat AD as EA if it can.
531 -- The parameter source-name and lib-name are omitted for the case
532 -- of a generic unit compiled with earlier versions of GNAT which
533 -- did not generate object or ali files for generics.
535 -- In fact W lines include implicit withs ???
537 -- -----------------------
538 -- -- L Linker_Options --
539 -- -----------------------
541 -- Following the W lines (if any, or the U line if not), are an
542 -- optional series of lines that indicates the usage of the pragma
543 -- Linker_Options in the associated unit. For each appearence of a
544 -- pragma Linker_Options (or Link_With) in the unit, a line is
545 -- present with the form:
549 -- where string is the string from the unit line enclosed in quotes.
550 -- Within the quotes the following can occur:
552 -- c graphic characters in range 20-7E other than " or {
553 -- "" indicating a single " character
554 -- {hh} indicating a character whose code is hex hh (0-9,A-F)
555 -- {00} [ASCII.NUL] is used as a separator character
556 -- to separate multiple arguments of a single
557 -- Linker_Options pragma.
559 -- For further details, see Stringt.Write_String_Table_Entry. Note
560 -- that wide characters in the form {hhhh} cannot be produced, since
561 -- pragma Linker_Option accepts only String, not Wide_String.
563 -- The L lines are required to appear in the same order as the
564 -- corresponding Linker_Options (or Link_With) pragmas appear in
565 -- the source file, so that this order is preserved by the binder
566 -- in constructing the set of linker arguments.
568 ---------------------
569 -- Reference Lines --
570 ---------------------
572 -- The reference lines contain information about references from
573 -- any of the units in the compilation (including, body version
574 -- and version attributes, linker options pragmas and source
577 -- ------------------------------------
578 -- -- E External Version References --
579 -- ------------------------------------
581 -- One of these lines is present for each use of 'Body_Version or
582 -- 'Version in any of the units of the compilation. These are used
583 -- by the linker to determine which version symbols must be output.
584 -- The format is simply:
588 -- where name is the external name, i.e. the unit name with either
589 -- a S or a B for spec or body version referenced (Body_Version
590 -- always references the body, Version references the Spec, except
591 -- in the case of a reference to a subprogram with no separate spec).
592 -- Upper half and wide character codes are encoded using the same
593 -- method as in Namet (Uhh for upper half, Whhhh for wide character,
594 -- where hh are hex digits).
596 -- ---------------------
597 -- -- D Dependencies --
598 -- ---------------------
600 -- The dependency lines indicate the source files on which the compiled
601 -- units depend. This is used by the binder for consistency checking.
602 -- These lines are also referenced by the cross-reference information.
604 -- D source-name time-stamp checksum [subunit-name] line:file-name
606 -- The time-stamp field contains the time stamp of the
607 -- corresponding source file. See types.ads for details on
608 -- time stamp representation.
610 -- The checksum is an 8-hex digit representation of the source
611 -- file checksum, with letters given in lower case.
613 -- The subunit name is present only if the dependency line is for
614 -- a subunit. It contains the fully qualified name of the subunit
615 -- in all lower case letters.
617 -- The line:file-name entry is present only if a Source_Reference
618 -- pragma appeared in the source file identified by source-name.
619 -- In this case, it gives the information from this pragma. Note
620 -- that this allows cross-reference information to be related back
621 -- to the original file. Note: the reason the line number comes
622 -- first is that a leading digit immediately identifies this as
623 -- a Source_Reference entry, rather than a subunit-name.
625 -- A line number of zero for line: in this entry indicates that
626 -- there is more than one source reference pragma. In this case,
627 -- the line numbers in the cross-reference are correct, and refer
628 -- to the original line number, but there is no information that
629 -- allows a reader of the ALI file to determine the exact mapping
630 -- of physical line numbers back to the original source.
632 -- Files with a zero checksum and a non-zero time stamp are in general
633 -- files on which the compilation depends but which are not Ada files
634 -- with further dependencies. This includes preprocessor data files
635 -- and preprocessor definition files.
637 -- Note: blank lines are ignored when the library information is
638 -- read, and separate sections of the file are separated by blank
639 -- lines to ease readability. Blanks between fields are also
642 -- For entries corresponding to files that were not present (and
643 -- thus resulted in error messages), or for files that are not
644 -- part of the dependency set, both the time stamp and checksum
645 -- are set to all zero characters. These dummy entries are ignored
646 -- by the binder in dependency checking, but must be present for
647 -- proper interpretation of the cross-reference data.
649 --------------------------
650 -- Cross-Reference Data --
651 --------------------------
653 -- The cross-reference data follows the dependency lines. See
654 -- the spec of Lib.Xref for details on the format of this data.
656 ----------------------
657 -- Global_Variables --
658 ----------------------
660 -- The table structure defined here stores one entry for each
661 -- Interrupt_State pragma encountered either in the main source or
662 -- in an ancillary with'ed source. Since interrupt state values
663 -- have to be consistent across all units in a partition, we may
664 -- as well detect inconsistencies at compile time when we can.
666 type Interrupt_State_Entry is record
667 Interrupt_Number : Pos;
668 -- Interrupt number value
670 Interrupt_State : Character;
671 -- Set to r/s/u for Runtime/System/User
673 Pragma_Loc : Source_Ptr;
674 -- Location of pragma setting this value in place
677 package Interrupt_States is new Table.Table (
678 Table_Component_Type => Interrupt_State_Entry,
679 Table_Index_Type => Nat,
680 Table_Low_Bound => 1,
682 Table_Increment => 200,
683 Table_Name => "Name_Interrupt_States");
685 -- The table structure defined here stores one entry for each
686 -- Priority_Specific_Dispatching pragma encountered either in the main
687 -- source or in an ancillary with'ed source. Since
688 -- have to be consistent across all units in a partition, we may
689 -- as well detect inconsistencies at compile time when we can.
691 type Specific_Dispatching_Entry is record
692 Dispatching_Policy : Character;
693 -- First character (upper case) of the corresponding policy name
695 First_Priority : Nat;
696 -- Lower bound of the priority range to which the specified dispatching
700 -- Upper bound of the priority range to which the specified dispatching
703 Pragma_Loc : Source_Ptr;
704 -- Location of pragma setting this value in place
707 package Specific_Dispatching is new Table.Table (
708 Table_Component_Type => Specific_Dispatching_Entry,
709 Table_Index_Type => Nat,
710 Table_Low_Bound => 1,
712 Table_Increment => 100,
713 Table_Name => "Name_Priority_Specific_Dispatching");
719 procedure Ensure_System_Dependency;
720 -- This procedure ensures that a dependency is created on system.ads.
721 -- Even if there is no semantic dependency, Targparm has read the
722 -- file to acquire target parameters, so we need a source dependency.
724 procedure Write_ALI (Object : Boolean);
725 -- This procedure writes the library information for the current main unit
726 -- The Object parameter is true if an object file is created, and false
729 -- Note: in the case where we are not generating code (-gnatc mode), this
730 -- routine only writes an ALI file if it cannot find an existing up to
731 -- date ALI file. If it *can* find an existing up to date ALI file, then
732 -- it reads this file and sets the Lib.Compilation_Arguments table from
733 -- the A lines in this file.
735 procedure Add_Preprocessing_Dependency (S : Source_File_Index);
736 -- Indicate that there is a dependency to be added on a preprocessing
737 -- data file or on a preprocessing definition file.