2 .\" Copyright (c) 2009, Sun Microsystems, Inc. All Rights Reserved
3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.
4 .\" See the License for the specific language governing permissions and limitations under the License. When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with
5 .\" the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
6 .TH LD.SO.1 1 "Oct 5, 2012"
8 ld.so.1 \- runtime linker for dynamic objects
17 \fB/lib/ld.so.1\fR [\fB-e\fR \fIenvar\fR] \fIdynamic-object\fR [\fIobject args\fR]...
23 Dynamic applications consist of one or more dynamic objects. A dynamic
24 application is typically a dynamic executable and one or more shared object
25 dependencies. As part of the initialization and execution of a dynamic
26 application, an \fBinterpreter\fR is called. This interpreter completes the
27 binding of the application to its shared object dependencies. In Solaris, this
28 interpreter is referred to as the runtime linker.
31 During the link-editing of a dynamic executable, a special \fB\&.interp\fR
32 section, together with an associated program header, is created. This section
33 contains a path name specifying the program's interpreter. An interpreter path
34 name can be specified when the executable is constructed using the \fB-I\fR
35 option to \fBld\fR(1), the link-editor. The default name supplied by the
36 link-editor is the name of the runtime linker, \fBld.so.1\fR.
39 During the process of executing a dynamic executable, the kernel maps the file,
40 and locates the required interpreter. See \fBexec\fR(2) and \fBmmapobj\fR(2).
41 The kernel maps in, and transfers control to, this interpreter. Sufficient
42 information is passed to the interpretor to allow the interpreter to continue
43 to bind, and then execute the application.
46 In addition to initializing an application, the runtime linker provides
47 services that allow the application to extend its address space. Additional
48 shared objects can be mapped, and symbols within the shared objects can be
52 The runtime linker performs the following functions:
57 A configuration file, if in existence, is processed. Configuration files can be
58 employed to alter default search paths, provide a directory cache, and provide
59 alternative object dependencies. See \fBcrle\fR(1). By default, for 32-bit
60 objects, the configuration file \fB/var/ld/ld.config\fR is used. For 64-bit
61 objects, the default configuration file \fB/var/ld/64/ld.config\fR is used.
62 Alternative configuration files can be specified with the \fBLD_CONFIG\fR
63 environment variable. Alternative configuration files can also be encoded
64 within a dynamic executable by using the \fB-c\fR option of \fBld\fR(1).
70 The runtime linker analyzes the application's dynamic information section,
71 \fB\&.dynamic\fR, to determine which shared object dependencies are required.
77 The runtime linker then locates and maps in these dependencies. The dynamic
78 information section of each dependency is then analyzed to determine if any
79 additional dependencies are required.
85 Once all the shared object dependencies are loaded, the runtime linker performs
86 any necessary relocations. These relocations bind the shared objects in
87 preparation for process execution.
93 Any initialization functions provided by the shared object dependencies and,
94 possibly, by the dynamic executable are called. The functions are called in the
95 reverse order of the topologically sorted dependencies. If cyclic dependencies
96 exist, the initialization functions are called using the sorted order with the
97 cycle removed. \fBldd\fR(1) can be used to display the initialization order of
98 shared object dependencies.
104 Control is passed to the application.
110 During the application's execution, the runtime linker can be called upon to
111 perform any delayed function binding.
117 If any shared objects are deleted from the process, finalization functions are
118 called. By default, these functions are called in the order of the
119 topologically sorted dependencies.
125 The application can also call upon the services of the runtime linker to
126 acquire additional shared objects by using \fBdlopen\fR(3C). Symbols provided
127 by these objects, can be bound to using \fBdlsym\fR(3C).
131 Further details on each of the previous topics can be found in the \fILinker
132 and Libraries Guide\fR.
135 The runtime linker uses a prescribed search path for locating the dynamic
136 dependencies of an object. The default search paths are the runpath recorded in
137 the object, followed by a series of defaults. For 32-bit objects, the defaults
138 are \fB/lib\fR followed by \fB/usr/lib\fR. For 64-bit objects, the defaults are
139 \fB/lib/64\fR followed by \fB/usr/lib/64\fR. These defaults component can be
140 modified using a configuration file that is created with \fBcrle\fR(1). The
141 runpath is specified when the dynamic object is constructed using the \fB-R\fR
142 option to \fBld\fR(1). The environment variable \fBLD_LIBRARY_PATH\fR can be
143 used to indicate directories to be searched before the default directories.
144 .SS "Command Line Usage"
147 Typically, the runtime linker is invoked indirectly through executing a dynamic
148 executable that declares the runtime linker as its interpreter. The runtime
149 linker can also be executed directly from the command line. This mechanism is
150 most often employed to experiment with new implementations of the runtime
151 linker. Arguments that are supplied on the command line consist of options that
152 are applicable to the runtime linker. Following these options is the name of
153 the dynamic object to be executed, and any options required by this object.
154 Effectively, the runtime linker replaces any interpreter specified by the
158 The following option is supported:
162 \fB\fB-e\fR\ envar\fR
165 Specify a runtime linker specific environment variable. See ENVIRONMENT
169 .SH ENVIRONMENT VARIABLES
172 Each environment variable can be specified with a \fB_32\fR or \fB_64\fR
173 suffix. This makes the environment variable specific, respectively, to 32-bit
174 or 64-bit processes. This environment variable overrides any non-suffixed
175 version of the environment variable that might be in effect. Environment
176 variables specified without a value, that have a \fB_32\fR or \fB_64\fR suffix,
177 effectively cancel any associated generic environment variable setting.
181 \fB\fBLD_AUDIT\fR, \fBLD_AUDIT_32\fR, and \fBLD_AUDIT_64\fR\fR
185 A colon-separated list of objects that are loaded by the runtime linker. As
186 each object is loaded, the object is examined for \fILink-Auditing\fR interface
187 routines. The routines that are present are called as specified in the
188 \fILink-Auditing\fR interface described in the \fILinker and Libraries
189 Guide\fR. Also, see the \fB-p\fR and \fB-P\fR options of \fBld\fR(1).
195 \fB\fBLD_BIND_LAZY\fR, \fBLD_BIND_LAZY_32\fR, and \fBLD_BIND_LAZY_64\fR\fR
199 The runtime linker's default mode of performing lazy binding can be enforced by
200 setting the environment variable \fBLD_BIND_LAZY\fR to any non-null value. This
201 setting causes the runtime linker to perform only \fBlazy\fR reference
202 relocations for all objects that are loaded into the process. Individual
203 objects can request that \fBlazy\fR reference relocations are performed when
204 the object is loaded. See the \fB-z\fR \fBnow\fR option of \fBld\fR(1), and
205 \fBdlopen\fR(3C) with the mode \fBRTLD_NOW\fR. Such requests to perform
206 \fBlazy\fR reference relocations are suppressed when \fBLD_BIND_LAZY\fR is in
209 If both \fBLD_BIND_LAZY\fR and \fBLD_BIND_NOW\fR are specified, then
210 \fBLD_BIND_NOW\fR takes precedence.
216 \fB\fBLD_BIND_NOW\fR, \fBLD_BIND_NOW_32\fR, and \fBLD_BIND_NOW_64\fR\fR
220 The runtime linker's default mode of performing lazy binding can be overridden
221 by setting the environment variable \fBLD_BIND_NOW\fR to any non-null value.
222 This setting causes the runtime linker to perform both \fBimmediate\fR
223 reference and \fBlazy\fR reference relocations for all objects that are loaded
224 into the process. Individual objects can request that \fBlazy\fR reference
225 relocations are performed when the object is loaded. See the \fB-z\fR \fBnow\fR
226 option of \fBld\fR(1), and \fBdlopen\fR(3C) with the mode \fBRTLD_NOW\fR.
228 If both \fBLD_BIND_NOW\fR and \fBLD_BIND_LAZY\fR are specified, then
229 \fBLD_BIND_NOW\fR takes precedence.
235 \fBLD_CAP_FILES\fR, \fBLD_CAP_FILES_32\fR, and \fBLD_CAP_FILES_64\fR
239 A comma-separated list of executables and shared libraries to which the
240 alternative capabilities specified by \fBLD_MACHCAP\fR, \fBLD_PLATCAP\fR,
241 \fBLD_HWCAP\fR and \fBLD_SFCAP\fR should apply.
243 Executables and libraries may be specified either by their SONAME or their
250 \fB\fBLD_CONFIG\fR, \fBLD_CONFIG_32\fR, and \fBLD_CONFIG_64\fR\fR
254 Provides an alternative configuration file. Configuration files can be employed
255 to alter default search paths, provide a directory cache, and provide alternate
256 object dependencies. See \fBcrle\fR(1).
262 \fB\fBLD_DEBUG\fR, \fBLD_DEBUG_32\fR, and \fBLD_DEBUG_64\fR\fR
266 Provides a comma, or colon-separated list of tokens to cause the runtime linker
267 to print debugging information to standard error. The special token \fBhelp\fR
268 indicates the full list of tokens available. The environment variable
269 \fBLD_DEBUG_OUTPUT\fR can also be supplied to specify a file to which the
270 debugging information is sent. The filename is suffixed with the process
271 \fBID\fR of the application generating the debugging information. See
278 \fB\fBLD_DEMANGLE\fR, \fBLD_DEMANGLE_32\fR, and \fBLD_DEMANGLE_64\fR\fR
282 Any symbol name used as part of a diagnostic message is shown as defined within
283 an \fBELF\fR file. When \fBLD_DEMANGLE\fR is set to any non-null value, the
284 runtime linker attempts to decode (demangle) any C++ symbol name.
290 \fB\fBLD_FLAGS\fR, \fBLD_FLAGS_32\fR, and \fBLD_FLAGS_64\fR\fR
294 Provides an alternative means of supplying environment variable information.
295 Any of the \fBLD_\fR\fIXXX\fR environment variables can be specified as a
296 \fIxxx\fR token. Multiple tokens can be supplied separated by commas. See
303 \fBLD_HWCAP\fR, \fBLD_HWCAP_32\fR, and \fBLD_HWCAP_64\fR
307 Specify a comma-separated set of alternative hardware capabilities. A
308 leading '+' indicates that the capabilities should be included in addition to
309 the default set, a leading '-' indicates that the capabilities should be
310 excluded from the default set, and neither indicates that the set should
311 replace the default set.
313 Capabilities may be specified either by name, or as hexadecimal integers with
314 an optional leading bracketed index number specifying the capabilities family.
316 LD_HWCAP=[1]01 # Sets CA_SUN_HW_1 to 0x1
317 LD_HWCAP=[2]20 # Sets CA_SUN_HW_2 to 0x20
328 Specify an alternative machine hardware capability name.
334 \fB\fBLD_LIBRARY_PATH\fR, \fBLD_LIBRARY_PATH_32\fR, and
335 \fBLD_LIBRARY_PATH_64\fR\fR
339 The \fBLD_LIBRARY_PATH\fR environment variable, if set, is used to enhance the
340 search path that the runtime linker uses to find dynamic dependencies.
341 \fBLD_LIBRARY_PATH\fR specifies a colon-separated list of directories that are
342 searched before the default directories. Also notice that \fBLD_LIBRARY_PATH\fR
343 adds additional semantics to \fBld\fR(1).
349 \fB\fBLD_LOADFLTR\fR, \fBLD_LOADFLTR_32\fR, and \fBLD_LOADFLTR_64\fR\fR
353 Filters are a form of shared object. Filters allow an alternative shared object
354 to be selected at runtime that provide the implementation for any symbols that
355 are defined within the filter. See the \fB-f\fR and \fB-F\fR options of
356 \fBld\fR(1). By default, the alternative shared object processing is deferred
357 until symbol resolution occurs against the filter. When \fBLD_LOADFLTR\fR is
358 set to any non-null value, any filters are processed immediately when the
359 filter is loaded. Also, see the \fB-z\fR \fBloadfltr\fR option of \fBld\fR(1).
365 \fB\fBLD_NOAUDIT\fR, \fBLD_NOAUDIT_32\fR, and \fBLD_NOAUDIT_64\fR\fR
369 Local auditing libraries can be defined within applications and shared objects.
370 See the \fB-p\fR and \fB-P\fR options of \fBld\fR(1). When \fBLD_NOAUDIT\fR is
371 set to any non-null value, the runtime linker ignores any local auditing
378 \fB\fBLD_NOAUXFLTR\fR, \fBLD_NOAUXFLTR_32\fR, and \fBLD_NOAUXFLTR_64\fR\fR
382 Auxiliary filters are a form of shared object. Auxiliary filters allow an
383 alternative shared object to be selected at runtime which provides the
384 implementation for any symbols that are defined within the filter. See the
385 \fB-f\fR option of \fBld\fR(1). When \fBLD_NOAUXFLTR\fR is set to any non-null
386 value, the runtime linker disables this alternative shared object lookup.
392 \fB\fBLD_NOCONFIG\fR, \fBLD_NOCONFIG_32\fR, and \fBLD_NOCONFIG_64\fR\fR
396 By default the runtime linker attempts to open and process a configuration
397 file. When \fBLD_NOCONFIG\fR is set to any non-null value, the runtime linker
398 disables this configuration file processing.
404 \fB\fBLD_NODIRCONFIG\fR, \fBLD_NODIRCONFIG_32\fR, and
405 \fBLD_NODIRCONFIG_64\fR\fR
409 Provides a subset of \fBLD_NOCONFIG\fR in that any directory cache information
410 provided in a configuration file is ignored.
416 \fB\fBLD_NODIRECT\fR, \fBLD_NODIRECT_32\fR, and \fBLD_NODIRECT_64\fR\fR
420 Direct binding information instructs the runtime linker to search directly for
421 a symbol in an associated object. See the \fB-B\fR \fBdirect\fR option of
422 \fBld\fR(1). Without direct binding, the symbol search performed by the runtime
423 linker follows the default model. When \fBLD_NODIRECT\fR is set to any non-null
424 value, the runtime linker ignores any direct binding information.
430 \fB\fBLD_NOENVCONFIG\fR, \fBLD_NOENVCONFIG_32\fR, and
431 \fBLD_NOENVCONFIG_64\fR\fR
435 Provides a subset of \fBLD_NOCONFIG\fR in that any environment variables
436 provided in a configuration file are ignored.
442 \fB\fBLD_NOLAZYLOAD\fR, \fBLD_NOLAZYLOAD_32\fR, and \fBLD_NOLAZYLOAD_64\fR\fR
446 Dependencies that are labeled for lazy loading are not loaded into memory until
447 explicit reference to the dependency has been made. See the \fB-z\fR
448 \fBlazyload\fR option of \fBld\fR(1). When \fBLD_NOLAZYLOAD\fR is set to any
449 non-null value, the runtime linker ignores a dependencies lazy loading label
450 and loads the dependency immediately.
456 \fB\fBLD_NOOBJALTER\fR, \fBLD_NOOBJALTER_32\fR, and \fBLD_NOOBJALTER_64\fR\fR
460 Provides a subset of \fBLD_NOCONFIG\fR in that any alternative object
461 dependencies provided in a configuration file are ignored.
467 \fB\fBLD_NOVERSION\fR, \fBLD_NOVERSION_32\fR, and \fBLD_NOVERSION_64\fR\fR
471 By default, the runtime linker verifies version dependencies for the primary
472 executable and all of its dependencies. When \fBLD_NOVERSION\fR is set to any
473 non-null value, the runtime linker disables this version checking.
479 \fB\fBLD_ORIGIN\fR, \fBLD_ORIGIN_32\fR, and \fBLD_ORIGIN_64\fR\fR
483 The immediate processing of \fB$ORIGIN\fR can be triggered by setting the
484 environment variable \fBLD_ORIGIN\fR to any non-null value. Before Solaris 9,
485 this option was useful for applications that invoked \fBchdir\fR(2) prior to
486 locating dependencies that employed the \fB$ORIGIN\fR string token. The
487 establishment of the current working directory by the runtime linker is now
488 default thus making this option redundant.
498 Specify an alternative platform hardware capability name.
504 \fB\fBLD_PRELOAD\fR, \fBLD_PRELOAD_32\fR, and \fBLD_PRELOAD_64\fR\fR
508 Provides a list of shared objects, separated by spaces. These objects are
509 loaded after the program being executed but before any other shared objects
510 that the program references. Symbol definitions provided by the preloaded
511 objects interpose on references made by the shared objects that the program
512 references. Symbol definitions provided by the preloaded objects do not
513 interpose on the symbol definitions provided by the program.
519 \fB\fBLD_PROFILE\fR, \fBLD_PROFILE_32\fR, and \fBLD_PROFILE_64\fR\fR
523 Defines a shared object to be profiled by the runtime linker. When profiling is
524 enabled, a profiling buffer file is created and mapped. The name of the buffer
525 file is the name of the shared object being profiled with a \fB\&.profile\fR
526 extension. By default, this buffer is placed under \fB/var/tmp\fR. The
527 environment variable \fBLD_PROFILE_OUTPUT\fR can also be supplied to indicate
528 an alternative directory in which to place the profiling buffer.
530 The profiling buffer contains \fBprofil\fR(2) and call count information. This
531 information is similar to the \fIgmon.out\fR information generated by programs
532 that have been linked with the \fB-xpg\fR option of \fBcc\fR. Any applications
533 that use the named shared object and run while this environment variable is
534 set, accumulate data in the profile buffer. See also NOTES. The profile buffer
535 information can be examined using \fBgprof\fR(1).
537 The \fBLD_PROFILE\fR profiling technique is an alternative to other techniques
538 that might be provided by the compilation system. The shared object being
539 profiled does not have to be instrumented in any way, and \fBLD_PROFILE\fR
540 should not be combined with a profile-instrumented application. See the
541 \fILinker and Libraries Guide\fR for more information on profiling shared
548 \fBLD_SFCAP\fR, \fBLD_SFCAP_32\fR, and \fBLD_SFCAP_64\fR
552 Specify a comma-separated set of alternative software capabilities. A
553 leading '+' indicates that the capabilities should be included in addition to
554 the default set, a leading '-' indicates that the capabilities should be
555 excluded from the default set, and neither indicates that the set should
556 replace the default set.
558 Capabilities may be specified either by name, or as hexadecimal integers.
564 \fB\fBLD_SIGNAL\fR, \fBLD_SIGNAL_32\fR, and \fBLD_SIGNAL_64\fR\fR
568 Provides a \fBnumeric\fR signal number that the runtime linker uses to kill the
569 process in the event of a fatal runtime error. See \fBthr_kill\fR(3C). By
570 default, \fBSIGKILL\fR is used. For example, providing the alternative signal
571 number \fB6\fR (\fBSIGABRT\fR), can provide for the creation of a core file to
572 aid debugging. See also the \fBRTLD_DI_SETSIGNAL\fR request to
578 Notice that environment variable names beginning with the
579 characters '\fBLD_\fR' are reserved for possible future enhancements to \fBld\fR(1) and
584 Secure processes have some restrictions applied to the evaluation of their
585 dependencies and runpaths to prevent malicious dependency substitution or
586 symbol interposition.
589 The runtime linker categorizes a process as secure if the \fBissetugid\fR(2)
590 system call returns true for the process.
593 For 32-bit objects, the default trusted directories that are known to the
594 runtime linker are \fB/lib/secure\fR and \fB/usr/lib/secure\fR. For 64-bit
595 objects, the default trusted directories are \fB/lib/secure/64\fR and
596 \fB/usr/lib/secure/64\fR. The utility \fBcrle\fR(1) can be used to specify
597 additional trusted directories that are applicable for secure applications.
598 Administrators who use this technique should ensure that the target directories
599 are suitably protected from malicious intrusion.
602 If an \fBLD_LIBRARY_PATH\fR family environment variable is in effect for a
603 secure process, only the \fBtrusted\fR directories specified by this variable
604 are used to augment the runtime linker's search rules.
607 In a secure process, runpath components that are provided by the application or
608 any of its dependencies are used, provided the component is a full path name,
609 that is, the path name starts with a '\fB/\fR'.
612 In a secure process, the expansion of the \fB$ORIGIN\fR string is allowed only
613 if the string expands to a \fBtrusted\fR directory. However, should a
614 \fB$ORIGIN\fR expansion match a directory that has already provided
615 dependencies, then the directory is implicitly secure. This directory can be
616 used to provide additional dependencies.
619 In a secure process, \fBLD_CONFIG\fR is ignored. However, a configuration file
620 that is recorded in a secure application is used. See the \fB-c\fR option of
621 \fBld\fR(1). A recorded configuration file must be a full path name, that is,
622 the path name starts with a '\fB/\fR'. A recorded configuration file that
623 employs the \fB$ORIGIN\fR string is restricted to known trusted directories.
624 Developers who record a configuration file within a secure application should
625 ensure that the configuration file directory is suitably protected from
626 malicious intrusion. In the absence of a recorded configuration file, a secure
627 process uses the default configuration file, if a configuration file exists.
631 In a secure process, \fBLD_SIGNAL\fR is ignored.
634 Additional objects can be loaded with a secure process using the
635 \fBLD_PRELOAD\fR, or \fBLD_AUDIT\fR environment variables. These objects must
636 be specified as \fBfull\fR path names or \fBsimple\fR file names. Full path
637 names are restricted to known \fBtrusted\fR directories. Simple file names, in
638 which no '\fB/\fR' appears in the name, are located subject to the search path
639 restrictions previously described. Simple file names resolve only to known
640 \fBtrusted\fR directories.
643 In a secure process, any dependencies that consist of simple filenames are
644 processed using the path name restrictions previously described. Dependencies
645 expressed as full path names or relative path names are used as is. Therefore,
646 the developer of a secure process should ensure that the target directory
647 referenced as a full path name or relative path name dependency is suitably
648 protected from malicious intrusion.
651 When creating a secure process, relative path names should \fBnot\fR be used to
652 express dependencies, or to construct \fBdlopen\fR(3C) path names. This
653 restriction should be applied to the application and to \fBall\fR dependencies.
656 \fBExample 1 \fRUsing LD_FLAGS to group environment variable information
659 The following use of \fBLD_FLAGS\fR is equivalent to setting the individual
660 environment variables \fBLD_BIND_NOW\fR and \fBLD_LIBRARY_PATH\fR for 32-bit
666 example% \fBLD_FLAGS_32=bind_now,library_path=/lib/one:/lib/two\fR
673 The following use of \fBLD_FLAGS\fR is equivalent to setting the individual
674 environment variables \fBLD_LIBRARY_PATH\fR and \fBLD_PRELOAD\fR for 64-bit
680 example% \fBLD_FLAGS_64=library_path=/lib/one/64,preload=foo.so\fR
689 \fB\fB/lib/ld.so.1\fR\fR
693 Default runtime linker.
699 \fB\fB/lib/libc.so.1\fR\fR
703 Alternate interpreter for \fBSVID ABI\fR compatibility.
709 \fB\fB/usr/lib/ld.so\fR\fR
713 \fBAOUT\fR (\fBBCP\fR) runtime linker.
719 \fB\fB/lib/secure\fR and \fB/usr/lib/secure\fR\fR
723 \fBLD_PRELOAD\fR location for secure applications.
729 \fB\fB/lib/secure/64\fR and \fB/usr/lib/secure/64\fR\fR
733 \fBLD_PRELOAD\fR location for secure 64-bit applications.
739 \fB\fB/lib/64/ld.so.1\fR\fR
743 Default runtime linker for 64-bit applications.
749 \fB\fB/var/ld/ld.config\fR\fR
753 Default configuration file for 32-bit applications.
759 \fB\fB/var/ld/64/ld.config\fR\fR
763 Default configuration file for 64-bit applications.
769 \fBcrle\fR(1), \fBgprof\fR(1), \fBlari\fR(1), \fBld\fR(1), \fBldd\fR(1),
770 \fBexec\fR(2), \fBissetugid\fR(2), \fBmmapobj\fR(2), \fBprofil\fR(2),
771 \fBdladdr\fR(3C), \fBdlclose\fR(3C), \fBdldump\fR(3C), \fBdlerror\fR(3C),
772 \fBdlinfo\fR(3C), \fBdlopen\fR(3C), \fBdlsym\fR(3C), \fBthr_kill\fR(3C),
773 \fBproc\fR(4), \fBattributes\fR(5)
776 \fILinker and Libraries Guide\fR
780 Care should be exercised when using \fBLD_PROFILE\fR in combination with other
781 process monitoring techniques, such as users of \fBproc\fR(4). Multiple process
782 monitoring techniques can result in deadlock conditions that leave the profile
783 buffer locked. A locked buffer blocks any processes that try to record
784 profiling information. To reduce this likelihood, the runtime linker's profile
785 implementation determines if the process is being monitored at startup. If so,
786 profiling of the process is silently disabled. However, this mechanism can not
787 catch monitoring processes that attach to the process during its execution.