pcref does not ken .cds segments

[canthony]

As part of the Y2K and time-zone issues, the pcref tool was used to locate references to
decode_clock_value_$date_time. prcef relies on data gathered by crossref, which analyzes
compiled/assembled segments to locate references to entry points.

However, .cds segments are not known to crorssref, has the compiled cds segments are not part of the built
code; only their output is.

The entry decode_clock_value_$date_time parameter zone was changed from char (3) to char (4); due to
pcref not searching the CDS segments, the change was not propagated to those segments.

Searching the Multics source reveals:

bound_pl1_.1.s.archive/pl1_version.cds

dcl decode_clock_value_$date_time
entry (fixed bin (71), fixed bin, fixed bin, fixed bin, fixed bin, fixed bin, fixed bin,
fixed bin (71), fixed bin, char (3), fixed bin (35));

This is the only date_time reference that I can locate in the .cds segments.

[Gary Dixon]

This ticket notes that the Multics cross_reference command does not capture information about references to subroutine entrypoints made by .cds executables (temporary programs which create data segments by initializing PL/I data structures and capturing their data in an object segment that is the result of the cds compilation).

PROBLEM:

This problem stems from the modus operandi of the cross_reference tool. It analyzes object segments, looking at the external entrypoints they define, the entrypoints they call, and the include files that were referenced in creating the object segment. That information is all stored as attributes in each object segment. Surprisingly, the cross_reference command doesn’t look any program source files!

The program compiled from the .cds source (known as the .cds executable program) only exists while the create_data_segment command is running.

The cds command operates as follows:

  - Invoke PL/I to compile the .cds source with -table information into 
    the .cds executable.
  - Invoke this .cds executable which:
      - initializes data structures declared in the .cds source (or in include files) 
        which it stores in a temporary segment, using values hard-coded into 
        the .cds source, or computed by the .cds source;
      - calls create_data_segment_ subroutine to:
          - use the symbol table information in the .cds executable to copy
            the initialized data structures from the temporary segment into 
            a fabricated object segment;
          - creates named entrypoints in the fabricated object locating the data 
            structure entrypoints in the object segment;
          - logs source file and include files used to compile the .cds source
            segment as attributes of the object segment.
  - The cds command cleans up by deleting temporary segments including the compiled 
    .cds executable.  Permanent output from the command is the fabricated object 
    segment.

The cross_reference command therefore knows about the source and include files used to create the fabricated object segment; this data is included in the cross reference output. But it has no visibility to the .cds executable which did the initializing. Therefore, external subroutines called to initialize data stored in the fabricated object (e.g., get_temp_segment_, release_temp_segment_, create_data_segment_, plus any subroutines needed to compute initial values for the data structure) are not known to cross_reference.

SOLUTION 1:

To remedy this problem, create_data_segment_ could copy all external link information from the .cds executable as link information in the fabricated object segment.

Cons: This might be misleading, since the initialized data structure doesn’t actually call these external subroutines; they were only used in fabricating the object. Strictly speaking, the external subroutines are referenced by the fabrication mechanism, but play no part in actual use/execution of the fabricated .cds object segment.

SOLUTION 2:

Another remedy might be to change create_data_segment and its supporting subroutine to save the .cds executable. It would be stored somewhere in the >ldd hierarchy, and could then be included in the list of input files for the cross_reference command.

Cons: This would involve changing the cds command and create_data_segment_ subroutine; changing tools which invoke the cds command to retain and install this new type of object segment; and changing the cross_reference creation tool to include such objects when generating the cross reference data. There would also be the start-up task of creating/installing .cds objects for all existing .cds segments.

SOLUTION 3:

Keep the current solution, since few .cds source files reference subroutines of any significance to the cross reference output.

RECOMMENDATION:

I think Solution 3 is still the right choice. It was the one made by the original cds developers. Solutions 1 and 2 offer few gains, for a significantly high cost.