Multics MTB-711

Multics Technical Bulletin MTB-711
Object MSFs.
To: Distribution
From: Dean Elhard
Date: 4 April 1986
Subject: Object Multi-Segment Files
1. Abstract
This MTB addresses the problem of creating packages which are too
large to fit into a single object segment but which have large
amounts of call traffic between code modules. It proposes a
method of creating a multi-segment executable object (Object MSF) |
which can be treated as a single entity for the purposes of |
execution, and file system operations. Object MSFs would resolve |
inter-component links without use of the dynamic linker, and |
would allow the elimination of external definitions and
entrypoints which should remain internal interfaces.
Revision 1:
 Modified external entry mechanism to enter via component 0
 transfer vector; introduced deferred initialization type
Revision 2:
 Modified external entry mechanism to have the dynamic linker
 indirect through partially snapped links to get actual
 target of definition to remedy problems with non-entry
 definitions.
Revision 3: |
 Modified to change names and address issues raised by MCRB. |
Changes are marked with change bars.
_________________________________________________________________
Multics project internal documentation. Not to be reproduced or
distributed outside the Multics project.
MTB-711 Multics Technical Bulletin
 Object MSFs.
Comments should be sent to the author:
 via Multics mail to:
 Elhard -at System-M
 via posted mail to:
 Dean Elhard
 Advanced Computing Technology Centre
 Foothills Professional Building
 1620 29th St., N.W.
 Calgary Alberta Canada T2N-4L7
 via telephone to:
 (403)-284-6400
 (403)-284-6427 (Elhard)
 via forum on System-M to:
 >udd>m>Elhard>mtgs>Very_Large_Objects (vlo)
Multics Technical Bulletin MTB-711
Object MSFs.
 TABLE OF CONTENTS
Section Page Subject
======= ==== =======
1 i Abstract
2 1 Preface
3 1 Introduction
3.1 1 . . Goal
3.2 1 . . References For This Document
4 2 Object Multi-Segment File Implementation
4.1 2 . . Problems
4.2 2 . . General Implementation
4.3 4 . . MSF map
4.4 5 . . Inter-Component Links
4.5 7 . . Indirect Definitions
5 9 Prelink First Reference Trap
6 10 External Variable Initialization
6.1 10 . . Deferred Initialization
6.2 11 . . External Initialization Example
7 12 Dynamic Linker Changes
8 13 User Ring Support
9 21 Object MSF Call Example
Multics Technical Bulletin MTB-711
Object MSFs.
2. Preface
The analysis of C language development, and experience with other |
third party software not developed specifically for Multics,
indicates a need for much of this software to run in an
environment where the entire package can be pre-linked in bound
segments independent of the size of the package. |
3. Introduction |
3.1. Goal |
My objective is to allow large packages, in which the resulting |
object code will not fit into a single segment, to be treated as
a single entity by the file system commands and by the dynamic
linker. Thesed object MSFs will permit software developed on |
other machines, which expect all references to be resolved
statically but which are too large to be bound in a single
segment, to be ported more easily.
3.2. References For This Document
1) Multics Programmers Reference Manual (10.2 AG91-04)
 (hereafter referred to as MPRM)
MTB-711 Multics Technical Bulletin
 Object MSFs.
4. Object Multi-Segment File Implementation |
The objective when implementing object MSFs is to minimize the |
amount of change to existing software and data structures while
adding the functionality necessary.
4.1. Problems
The basic problem in object MSF implementation is how to spread |
object code among a number of segments in such a way that it is |
as transparent as possible to the user. Transparent means that |
it should be possible to do the following operations:
 - invoke the object MSF from command level without special |
 syntax.
 - call subroutines within an object MSF using normal syntax |
 and without any changes required to the links (and
 therefore compilers).
 - use standard tools on the object MSF or components of the |
 MSF to report object information (such as print_link_info, |
 etc.)
 - call out from an object MSF without any special |
 consideration.
There are other problems inherent in any design that requires the
code for an object to be split into discrete parts. In
particular, we must find a means of specifying and resolving
"internal" references to the text, static, linkage, or symbol
sections of another component, and we must insure that external
variable references (via *system links) are initialized properly
regardless of which component declared the variable
initialization and which component first references the variable.
4.2. General Implementation
The general implementation consists of a Multi-Segment File
containing slightly modified standard object segments. (For a
desription of a standard object segment, see the MPRM.) This
allows the object MSF to be moved, copied or deleted with minimal |
changes to existing software. The linker will resolve the object |
MSF as a link target in the same manner as is currently done, via |
the names on the object segment or MSF. |
Multics Technical Bulletin MTB-711
Object MSFs.
There are two types of components in an object MSF: |
Component 0
 Component 0 is nothing more than a transfer vector to the
 actual entrypoints in the other components. The transfer
 vectors are done via definitions with the indirect flag set,
 and partially snapped links. Component 0 contains only
 partially snapped links, definitions, an msf_map, and the |
 msf_prelink_ first reference trap. |
Executable Components
 These are basically standard object segments except that
 they contain an msf_map, and partially snapped links to the |
 other executable components.
MTB-711 Multics Technical Bulletin
 Object MSFs.
4.3. MSF map |
To identify an object MSF and its extent (in terms of the number |
of components), a new structure has been created and inserted
into the definition section of an object MSF component. This is |
the msf_map. To locate the msf_map, a previously unused 18 bit |
field in the definition header has been used to specify the
offset of the map from the base of the definition section. The
msf_map has the following form: |
 dcl 01 msf_map aligned based, |
 02 version char (8),
 02 component_count fixed bin,
 02 my_component fixed bin,
version
 Is the version of the structure and must be "msfmp1.0". |
component_count
 Is the number of components in the object MSF. |
my_component
 Is the number of the current component in the range 0 to
 component_count-1.
Multics Technical Bulletin MTB-711
Object MSFs.
4.4. Inter-Component Links
Resolution of references internal to the MSF, but between |
components, is done by the creation of partially snapped links in
the linkage section of the calling component. These links take
advantage of knowledge of the target. A normal unsnapped link is
an ITS pointer with a fault_tag_2 modifier, and other fields used
to contain linkage information. A partially snapped link is also
based on an ITS pointer but has a fault_tag_3 modifier in place |
of the ITS modifier.
 dcl 01 partial_link based aligned, |
 02 type fixed bin (3) unsigned unaligned,
 02 component fixed bin (15) unsigned unaligned,
 02 mbz1 bit (12) unaligned,
 02 tag bit (6) unaligned,
 02 offset fixed bin (18) unsigned unaligned,
 02 mbz2 bit (3) unaligned,
 02 bit_offset fixed bin (6) unsigned unaligned,
 02 mbz3 bit (3) unaligned,
 02 mod bit (6) unaligned;
type
 This field is used to encode the target section of the link.
 The values used are the same as those used in a definition
 to indicate the target section.
 - Text section = 0
 - Linkage section = 1
 - Symbol section = 2
 - Static section = 4
component
 Is used to store the number of the target segment in the
 range 0 to component_count-1. At execution time, this value
 will be replaced depending on the target section as encoded
 in type.
 Text section - the component field will be replaced by
 the segment number of the target
 segment.
 Linkage section - the component field will be replaced by
 the segment number of the segment
 containing the copied linkage section.
MTB-711 Multics Technical Bulletin
 Object MSFs.
 Symbol section - the component field will be replaced by
 the segment number of the target
 segment.
 Static section - the component field will be replaced by
 the segment number of the segment
 containing the copied static section.
mbz1
 Is unused and must be ""b.
tag
 Is set to fault_tag_3 initially ("47"b3) to distinguish it
 from a normal unsnapped link or a snapped link with an ITS
 modifier ("43"b3). This is to insure that if the link does
 not get snapped somehow, a reference through it will fault.
 When the link is snapped, this field will be replaced by an
 ITS modifier. Note that this link is not snapped as a
 result of a hardware reference, except as a by-product of
 snapping a link to a previously unreferenced object MSF. In |
 this case, one partial link is snapped by the dynamic linker |
 to determine the target of the indirect definition. This
 must be done by the dynamic linker since we must finish
 snapping the link faulted on prior to the execution of the
 first-reference traps which normally would snap the partial
 links.
offset
 This field is the offset within the section identified by
 type to the target of the partial link. It is analogous to
 the thing_relp value in the corresponding definition in the
 target segment.
mbz2
 Is unused and must be ""b.
bit_offset
 Is the bit offset of the target of the link. Since a link
 target may not be on other than a word boundary, this field
 must be 0.
mbz3
 Is unused and must be ""b.
modifier
 Is the modifier of the link.
Multics Technical Bulletin MTB-711
Object MSFs.
4.5. Indirect Definitions
When handling snapping of links to an object MSF, it is desirable |
to restrict the definition search to component 0. It is also |
desirable to have the link snap directly to the final target (in |
whatever component) so that references to non-entry targets can |
be referenced correctly. In order to do this, a new definition |
flag will be defined. The indirect flag will indicate that the |
target of the definition is a partially snapped link pointing to
the actual target of the definition in another component. When
the dynamic linker is snapping the link, it will check to see if
the definition has the indirect bit set, chase the partial link,
and snap it if necessary. Snapping the partial link by the
dynamic linker will only be required on the first reference to a
given segment. This is because the link snapping must be
completed prior to the execution of the first reference trap
which will snap the rest of the partial links.
 dcl 01 definition aligned based (def_ptr),
 02 forward_relp fixed bin (18) unsigned unaligned,
 02 backward_relp fixed bin (18) unsigned unaligned,
 02 thing_relp fixed bin (18) unsigned unaligned,
 02 flags unaligned,
 03 new bit (1),
 03 ignore bit (1),
 03 entry bit (1),
 03 retain bit (1),
 03 argcount bit (1),
 03 descriptors bit (1),
 03 indirect bit (1),
 03 unused bit (8);
 02 class fixed bin (3) unsigned unaligned,
 02 name_relp fixed bin (18) unsigned unaligned,
 02 segname_relp fixed bin (18) unsigned unaligned;
forward_relp
 is a thread (relative to the base of the definition section)
 to the next definition. The thread terminates when it
 points to a word that is 0. This thread provides a single
 sequential list of all the definitions within the definition
 section.
backward_relp
 is a thread (relative to the base of the definition section)
 to the preceeding definition.
MTB-711 Multics Technical Bulletin
 Object MSFs.
thing_relp
 is the offset of the target of the symbolic definition |
 within the section designated by the class variable |
 (described below). |
flags
 contains binary indicators that provide additional
 information about this definition:
 new
 "1"b definition section has new format
 "0"b definition section has old format
 ignore
 "1"b definition does not represent an external symbol
 and is therefor ignored by the Multics linker
 "0"b definition represents an external symbol
 entry
 "1"b definition of an entry point (a variable reference
 through a transfer of control instruction)
 "0"b definition of an external symbol that does not
 represent a standard entry point
 retain
 "1"b definition must be retained in the object segment
 (by the binder)
 "0"b definition can be deleted from the object segment
 (by the binder)
 argcount (obsolete)
 "1"b definition includes a count of the argument
 descriptors
 "0"b no argument descriptor information is associated
 with the definition
 descriptors (obsolete)
 "1"b definition includes an array of argument
 descriptors
 "0"b no valid descriptors exist in the definition
 indirect
 "1"b definition refers to a partial link to the actual
 target of the symbolic definition which resides in
 another MSF component |
 "0"b definition refers directly to the target of this
 symbolic definition
 unused
 is reserved for future use and must be "0"b
Multics Technical Bulletin MTB-711
Object MSFs.
class
 this field contains a code indicating the section of the
 object segment to which thing_relp is relative. Codes are:
 0 text section
 1 linkage section
 2 symbol section
 3 this symbol is a segment name
 4 static section
name_relp
 is an offset (relative to the base of the definition
 section) to an aligned acc string representing the
 definition's symbolic name.
segname_relp
 is an offset (relative to the base of the definition
 section) to the first class-3 definition of this definition
 block.
5. Prelink First Reference Trap
The presnapping of links is accomplished using a first reference
trap to the procedure msf_prelink_. This first reference trap |
exists only in component 0. Since all calls into the MSF are |
done through the component 0 transfer vector, the trap should
always be properly executed. The msf_prelink_ trap performs the |
following functions:
 - initiates all of the components.
 - gets pointers to the linkage and static sections of the
 components, combining the linkage sections if necessary.
 - scans the linkage section of each component, beginning
 with component 0, looking for links with a fault_tag_3 tag
 indicating a partially snapped internal link. These links
 are then resolved as indicated above.
 - gets the first reference trap blocks from each of the
 other components and executes the firstref traps for all
 of the components except component 0. (since component 0
 was the segment actually found by the search, we have the
 dynamic linker run the component 0 traps, even though the
 eventual target of the link is in another component.
 Since component 0 is an synthetic construct, and does not
 contain and code or data, this should be the only trap
 procedure for component 0.) Before each trap procedure is
 called, a check is made to see if the trap procedure is
 msf_prelink_. If so, the trap is ignored since the |
 running of msf_prelink_ once will initialize the entire |
 MSF. |
MTB-711 Multics Technical Bulletin
 Object MSFs.
Once the msf_prelink_ trap has run, all inter-component links |
will be properly snapped. This increases the startup overhead |
when calling into an object MSF for the first time, but will |
probably result in faster overall execution. All the links are |
snapped without taking any faults and the majority of the work is
done when the links are created, rather than at execution time.
6. External Variable Initialization
A problem associated with this implementation of object MSFs, is |
external variable initialization. The init_info for *system
links can be very large, and we don't know which component will
generate the first reference to the variable, and do the
initialization. The mechanisms currently in place would require
a copy of the init_info in each component so that the variable is
initialized correctly in any case. This results in an incredible
waste of space. In order to avoid this problem, we propose the
creation of a new type of init_info which will allow the
elimination of the duplicate init_info.
6.1. Deferred Initialization
When an object MSF is created, all references to a given external |
variable will be examined and a single init_info created. This |
init_info will be placed in one of the components and all
references within that component will be properly resolved. In
each of the other components referencing the same variable, a
link is generated with an init_info of type INIT_DEFERRED.
The structure for a deferred init_info (shown below) contains a
standard header, and two relpointers that are used to locate the
actual init_info. The target_relp value is an offset relative to
the base of the linkage section to a partially snapped link
(which should by now be an ITS pointer) pointing to the base of
the linkage section of the component containing the actual
init_info. The link_relp value is the offset within the target
linkage section of the link which references the actual
init_info. From this information the dynamic linker can extract
the definition section and original linkage section of the target
segment, and then get a pointer to the real init_info.
 dcl 01 link_init_deferred aligned based (link_init_ptr),
 02 header aligned,
 03 n_words fixed bin (35),
 03 type fixed bin,
 02 target_relp fixed bin (18) unsigned unaligned,
 02 link_relp fixed bin (18) unsigned unaligned;
Multics Technical Bulletin MTB-711
Object MSFs.
n_words
 is the length of the variable to be allocated in words.
type
 is the initialization type. For a deferred_initialization,
 this value will be 6.
target_relp
 is the offset (relative to the base of the linkage section)
 of a partial link which, when resolved, points to the base
 of the linkage section of the component containing the
 actual init_info.
link_relp
 is the offset (relative to the base of the target components
 linkage section) of the link which references the actual
 init_info being used.
6.2. External Initialization Example
When a deferred_init *system link is referenced, the dynamic
linker (link_snap) is invoked. Link_snap extracts the
initialization info to pass to set_ext_variable_. Noting that
the type of initialization is deferred, link_snap uses the
target_relp value in the init_info to find a pointer (actually a
partially snapped link, which will be snapped by this time) to
the base of the linkage section for the component containing the
actual init_info.
After validating that the definition and original_linkage
pointers in the linkage_header are valid, the link_relp value
will then be applied to the original linkage section to find the
unsnapped link which refers to the real init_info. The link is
then decoded to extract the expression word, type_pair and
init_info in turn. The init_info pointer extracted from the
original faulting link is then replaced by a pointer to the real
init info. The subroutine set_ext_variable_$for_linker is then
called to return the variable node and the link snapping
continues as if the init_info were stored in the original object.
MTB-711 Multics Technical Bulletin
 Object MSFs.
7. Dynamic Linker Changes
The dynamic linker requires modification for four reasons:
 1) Non-segment branches are currently ignored when searching
 for a name.
 2) Calls out of an MSF must use another level of indirection |
 up the storage heirarchy when evaluating the |
 "referencing_dir" search rule. The referencing directory
 for an object MSF should be the directory containing the |
 MSF rather than the MSF directory itself. |
 3) The indirection to the link containing the init_info
 required by deferred initialization must be added.
 4) The evaluation of indirect definitions and the possible
 snapping of a partial linkmust be added.
The first two problems are solved by modifying fs_search. The |
calling sequence of fs_search will be changed to add another |
parameter, which will identify the referencing segment as an |
object MSF component. When evaluating the referencing_dir rule, |
this parameter will be checked. If the caller is an object MSF, |
another level of indirection is used to search the containing
directory. Also, when an attempt to initiate the name fails and |
returns the error code error_table_$dirseg, which indicates that |
the named object exists but is a directory branch, we check to |
see if the branch is an MSF. If it is, we attempt to initiate
component 0 and return a pointer to it. The refname given is
added to component 0 of the MSF. If the directory is not an MSF, |
it is ignored.
The third problem is solved by changing link_snap to check the
init_info prior to calling set_ext_variable_$for_linker and to
get the new init_info if the type is deferred.
The fourth problem is solved by changing fs_search and link_snap.
The changes to fs_search involve adding a new entrypoint,
fs_search$same_directory which will be used by link_snap to
initiate the target component of the partial link.
fs_search_$same_directory will utilize the same mechanism as it |
currently used to evaluate the referencing_dir search rule, and |
will search ONLY that directory. If found, the named segment |
will be initiated with a null refname. The syntax for the new
subroutine is:
 dcl fs_search$same_directory (ptr, char(*), ptr, fixed bin(35));
 call fs_search$same_directory (ref_ptr, refname, seg_ptr, code);
Multics Technical Bulletin MTB-711
Object MSFs.
The definition searching algorithm of link_snap will be modified
to check the indirect flag in the definition and, if set,
validate that the definition refers to the linkage section. If
the target of the definition is already snapped (by the first
reference trap), that pointer is returned as the target of the
definition. If it is not snapped, the dynamic linker will call
fs_search$same_directory to initiate the target, combine its
linkage section, snap the partial link, and then return the value
of the now-snapped link as the target of the definition. Note
that this operation performs two linkage_section allocations, but
first_reference traps are only run on behalf of component 0.
This is because the msf_prelink_ trap is responsible for running |
any traps in the other components.
8. User Ring Support
In addition to the support procedures required for execution of
an object MSF such as msf_prelink_, a number of other user ring |
procedures will have to be modified in order to give proper
support for object MSFs. |
fs_standard_object_
 The procedure fs_standard_object_ will have to be changed to
 permit the setting of execute permission on a Multi-Segment
 File.
list, ls
 The list command should be changed to properly report the
 acl mode on Multi-Segment Files.
where, wh
 The where command will have to be modified to handle
 location of MSF components in the cases where it searches
 for the target manually rather than calling hcs_$make_ptr.
print_link_info, pli
 The print_link_info command should be modified to detect
 that the object specified is an MSF and perform the |
 equivalent of what is currently done on each of the
 components.
date_compiled, dtc
 The date_compiled command should be modified to detect an |
 MSF and check all of the components. |
MTB-711 Multics Technical Bulletin
 Object MSFs.
cv_entry_, cv_ptr_
 The cv_entry_ and cv_ptr_ subroutines will have to be
 modified to initiate the proper segment when called with an
 absolute or relative pathname to an object MSF. This is |
 because component 0 should be initiated with the given |
 refname in that case.
find_command_
 The find_command_ subroutine will have to be modified to
 check if the target is an MSF when called with a relative or |
 absolute pathname and initiate component 0 with the given
 refname.
term_
 The term_ subroutines will have to be modified to terminate
 and uncombine the linkage sections for all components of an |
 object MSF. |
set_fortran_common, sfc
 The set_fortran_common command will have to be changed to
 look in all the components of an object MSF for external |
 variable links.
dprint, dp
 The dprint command will have to be modified to detect
 whether an MSF being dprinted is an object MSF and reject |
 the request as is currently done for single segment |
 binaries.
enter_output_request, eor
 The enter_output_request command will have to be modified in
 the same manner as the dprint command.
create_data_segment_ |
 The create_data_segment_ subroutine currently produces |
 object segments with malformed definition lists causing |
 object segments created by cds to appear to have an msf_map. |
 This problem occurs because the previously MBZ field in the |
 definition header that is now being used to locate the |
 msf_map is in the same position as the backward_relp value |
 in a definition. create_data_segment_ is threading the |
 header into the backward list instead of terminating it from |
 the first definiiton. |
 |
exists |
 The exists command will have to be modified to allow |
 selection of object MSFs and object files. |
Multics Technical Bulletin MTB-711
Object MSFs.
object_segments, osegs |
 This command should be modified (and possibly renamed) to |
 detect object segments and/or MSFs. |
In order to facilitate the changes to existing software, some
other new subroutines will be created to deal with object files |
in a consistent manner. These subroutines will form a library
that can be used to deal with objects in a manner less dependent
on knowledge of the object segment format by the caller.
MTB-711 Multics Technical Bulletin
 Object MSFs.
Syntax:
dcl object_lib_$initiate entry (char(*), char(*), char(*),
 bit (1), ptr, fixed bin (24), bit (1), fixed bin (35)); |
call object_lib_$initiate (dirname, entryname, refname,
 validate_sw, seg_ptr, bit_count, msf_sw, code); |
Function:
Initiates the executable binary specified, with the given
refname, terminating the refname as required and returning a
pointer and bit count. The target is optionally checked to |
insure that it is actually an object segment or MSF, and that its |
status as an object MSF is consistent. |
Arguments:
dirname
 is the directory name of the object to be initiated.
 (Input)
entryname
 is the entry name of the object to be initiated. (Input)
refname
 is the reference name to be placed on the object when it is
 initiated. If the object is an object MSF, the reference |
 name will be placed on component 0. (Input) |
validate_sw |
 is a switch to select whether of not the target segment or |
 MSF is checked to see if it is a valid executable binary. |
 (Input) |
seg_ptr
 is a pointer to the object. If the object is an object MSF, |
 a pointer to component 0 will be returned. (Output) |
bit_count |
 is the bit_count of the segment pointed to by seg_ptr. If |
 the target is an MSF, it is the bit count of component 0. |
 (Output) |
msf_sw |
 is a flag indicating whether the object specified is an |
 object MSF. (Output) |
code
 is a standard status code.
Multics Technical Bulletin MTB-711
Object MSFs.
Syntax:
dcl object_lib_$init_no_clear entry (char(*), char(*), char(*),
 bit (1), ptr, fixed bin (24), bit (1), fixed bin (35)); |
call object_lib_$init_no_clear (dirname, entryname, refname,
 validate_sw, seg_ptr, bit_count, msf_sw, code); |
Function:
Initiates the executable binary specified, with the given
refname, terminating the refname as required and returning a
pointer. If the refname is already in use, term_$no_clear is
called rather than term_$single_refname. This entrypoint is
intended for use only by find_command_ since it will not clear
find_command_'s associative memory of entrypoints which is
assumed to be managed manually by find_command_. The target is
optionally checked to insure that it is actually an object |
segment or MSF, and that its status as an object MSF is |
consistent. |
Arguments:
dirname
 is the directory name of the object to be initiated.
 (Input)
entryname
 is the entry name of the object to be initiated. (Input)
refname
 is the reference name to be placed on the object when it is
 initiated. If the object is an object MSF, the reference |
 name will be placed on component 0. (Input) |
validate_sw |
 is a switch to select whether of not the target segment or |
 MSF is checked to see if it is a valid executable binary. |
 (Input) |
seg_ptr
 is a pointer to the object. If the object is an object MSF, |
 a pointer to component 0 will be returned. (Output) |
bit_count |
 is the bit count of the segment pointed to by seg_ptr. If |
 the target is an MSF, it is the bit count of component 0. |
 (Output) |
msf_sw |
 is a flag indicating whether the object specified is a MSF. |
 (Output)
code
 is a standard status code.
MTB-711 Multics Technical Bulletin
 Object MSFs.
Syntax: |
 |
dcl object_lib_$get_component_info entry (ptr, ptr, char(8), |
 char(*), ptr, fixed bin(35)); |
call object_lib_$get_component_info (segp, areap, version_reqd, |
 oi_type, infop, code); |
 |
Function: |
 |
Returns structural and identifying information about an object |
segment or MSF. Varying amounts of information may be returned |
depending on the value of the oi_type parameter. |
 |
Arguments: |
 |
segp |
 is a pointer to the segment to be examined. This may be a |
 single segment or a component of an object MSF. If it is a |
 component of an object MSF (determined by the presence or |
 absence of an msf_map in the object) info is returned for |
 all of the components. (Input) |
areap |
 is a pointer to an area in which the output structure is to |
 be allocated. If this pointer is null, the system_free_area |
 is used. (Input) |
version_reqd |
 is the version of the output structure desired. Currently |
 only one version is supported. This value should be |
 component_info_version_1 (declared in |
 object_lib_defs.incl.pl1) (Input) |
oi_type |
 is the type of object info desired by the caller. Four |
 values are supported: |
 "none" No object info is filled into the structure. Only |
 the segment pointers, bit_count, and terminate |
 flag is set. |
 "brief" Object info is filled in for each component by |
 calling object_info_$brief for each component. |
 "display" Object info is filled in for each component by |
 calling object_info_$display for each component. |
 "long" Object info is filled in for each component by |
 calling object_info_$long for each component. |
infop |
 is a pointer to a component_info structure allocated by |
 object_lib_$get_component_info. (Output) |
code |
 is a standard status code. (Output) |
 |
Notes: |
Multics Technical Bulletin MTB-711
Object MSFs.
The component info structure returned has the following |
definition (declared in object_lib_defs.incl.pl1): |
 |
 dcl 01 component_info aligned based (comp_infop), |
 02 version char (8), |
 02 flags aligned, |
 03 msf bit (1) unaligned, |
 03 mbz bit (35) unaligned, |
 02 max fixed bin, |
 02 comp (0:max_component |
 refer (component_info.max)), |
 03 segp ptr, |
 03 bc fixed bin (24), |
 03 flags aligned, |
 04 terminate bit (1) unaligned, |
 04 mbz bit (35) unaligned, |
 03 info like object_info; |
 |
where: |
 |
version |
 is the version number of the structure. It is currently |
 "cinfo 1.0". The named constant for this value |
 component_info_version_1 is declared in |
 object_lib_defs.incl.pl1 |
msf |
 is a flag indicating that the object in question is an |
 object MSF. |
max |
 is the number of the largest component in the file. |
comp |
 contains the per-component information. |
segp |
 is a pointer to the N'th component of the file. |
bc |
 is the bit_count of the N'th component of the file. |
terminate |
 is a flag indicating that the N'th component was unknown |
 before object_lib_$get_component_info was called and should |
 therefor be terminated by the caller. |
info |
 is identical to the structure object_info (declared in |
 object_info.incl.pl1) for a description of the fields in |
 this section see object_info_. |
MTB-711 Multics Technical Bulletin
 Object MSFs.
Syntax:
dcl object_lib_$get_def_target entry (ptr, fixed bin(24), char(*),
 char(*), bit(1), ptr, fixed bin(35));
call object_lib_$get_def_target (segp, bc, segname, offsetname,
 live_sw, targetp, code);
Function:
Searches the segment specified by segp for a definition matching
segname and offsetname and returns a pointer to the target of the
definition. If the segment specified is component 0 of an object |
MSF, the target pointer return points to the eventual target of |
the definition (in some component other than component 0). If
live_sw is "1"b, and the definition found refers to the static or
linkage section, the targetp value returned will be in the live
copy of the linkage or static section, respectively. If it is
"0"b, the value returned will point to the template in the object
segment.
Arguments:
segp
 is a pointer to the segment to search. (Input)
bc
 is the bit_count of the segment to search. (Input)
segname
 is the segname to search for. (Input)
offsetname
 is the name of the definition to search for. (Input)
live_sw
 specified whether definitions which reference the static or
 linkage section of the object should return a pointer
 relative to the live copy pointed to by the LOT/ISOT or to
 the static template stored in the object segment itself.
 (Input)
targetp
 is a pointer to the eventual target of the definition.
 (Output)
code
 is a standard status code. (Output)
Multics Technical Bulletin MTB-711
Object MSFs.
9. Object MSF Call Example |
The following is a step-by-step example of the process involved
in snapping a link to an object MSF. |
1) The calling procedure references an unsnapped type 4 link and
 takes a fault. link_snap$link_fault is invoked via the fault
 handling mechanism.
2) Link_snap determines the type of link and gets the segname
 and entryname ACC strings from the definition section.
3) Link_snap calls fs_search to locate the target segment of the
 link.
4) Fs_search applies each search rule looking for the given
 segname. If the initiated_segments rule is used to find the
 name, the refname will be on component 0 of the object MSF, |
 which is the proper pointer to be returned to link_snap.
 If the referencing_dir rule is being evaluated, the calling
 procedure is checked to see if it is an object MSF. If it |
 is, another level of indirection is introduced when
 determining the directory to be used as the referencing
 directory.
 If a directory is being searched, and the call to initiate_
 returns the error code error_table_$dirseg, which indicates |
 that a branch with that name exists but is a directory,
 fs_search calls status_$mins to see if the directory has a
 non-zero bit count (ie. if it is an MSF). If not, the
 directory is ignored. If it is an MSF, component 0 of the |
 MSF is initiated with the given refname and the pointer to |
 component 0 is returned.
5) Pointers are derived to the linkage, static, text, and symbol
 sections of the target, combining the linkage and static
 sections if necessary. If a first reference trap block is
 present when the linkage section is copied, a flag is set in
 the linkage header indicating that the traps must be run.
6) Link_snap calls get_defptr_ to find the definition.
7) The indirect bit is checked to see if the target is in
 another component. If it is, the target of the definition is
 checked to see if it an ITS pointer. If it is, the value is
 used as the target of the definition. If it is not,
 fs_search$same_directory is called to initiate the target,
 pointers are derived to the target sections by calling
 link_man$other_linkage, and the link is resolved by applying
 the offset to the appropriate section pointer.
MTB-711 Multics Technical Bulletin
 Object MSFs.
8) A pointer to the link target is calculated, and written into
 the link.
9) The machine conditions are adjusted so that the fault can be
 restarted without taking another linkage fault.
10) Link_snap calls trap_caller_caller_ to create a stack frame
 on the user ring stack, simulating a call to
 link_trap_caller_, which will actually call the
 first_reference traps, in the user ring.
11) Trap_caller_caller_ calls signaller$for_linker to transfer
 control back to the user ring to run link_trap_caller_ and
 handle cleanup of the ring 0 environment.
12) Link_trap_caller_ runs the first reference traps in the
 target segment. In the case of an object MSF, the first trap |
 will be a call to msf_prelink_ passing a type 1 *link|0 |
 reference as a parameter.
13) msf_prelink_ locates the msf_map in the object segment, |
 determines the number of components, and the current
 component number, and initiates each of the MSF components. |
14) Pointers to the copied linkage and static sections are
 derived for each MSF component. If the linkage section has |
 not been copied yet, hcs_$combine_linkage is called to do so.
15) The linkage sections of each of the MSF components are |
 scanned, looking for links with a "47"b3 fault_tag_3 tag, |
 which indicates a partially snapped link. These are resolved |
 as indicated above.
16) The copied linkage section headers are checked to see if
 there are first reference traps in the other components. (In
 an object MSF, there should be at least one first reference |
 trap in each component, but we check anyway.) If there are,
 we snap the links used by the trap, check the target of the
 call link to make sure we are not re-invoking msf_prelink_, |
 and then call the trap procedure. Traps to msf_prelink_ in |
 other components are ignored. Since the traps in the current
 component are already being run by link_trap caller, we do
 not run them again.
17) msf_prelink_ returns, and link_trap_caller_ continues running |
 any other first reference traps in the component 0.
Multics Technical Bulletin MTB-711
Object MSFs.
18) link_trap_caller_ returns. Due to the stack frame created by
 ring 0 and the modified machine conditions, we essentially
 return to the point just prior to the linkage fault. The
 calling procedure now re-tries the reference using the
 snapped link.
 

AltStyle によって変換されたページ (->オリジナル) /