1.\" Copyright (c) 2001, 2010, Oracle and/or its affiliates. All rights reserved.
2.\"
3.\" CDDL HEADER START
4.\"
5.\" The contents of this file are subject to the terms of the
6.\" Common Development and Distribution License (the "License").
7.\" You may not use this file except in compliance with the License.
8.\"
9.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
10.\" or http://www.opensolaris.org/os/licensing.
11.\" See the License for the specific language governing permissions
12.\" and limitations under the License.
13.\"
14.\" When distributing Covered Code, include this CDDL HEADER in each
15.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
16.\" If applicable, add the following below this CDDL HEADER, with the
17.\" fields enclosed by brackets "[]" replaced with your own identifying
18.\" information: Portions Copyright [yyyy] [name of copyright owner]
19.\"
20.\" CDDL HEADER END
21.\"
22.Dd December 3, 2021
23.Dt CHECK_RTIME 1ONBLD
24.Os
25.Sh NAME
26.Nm check_rtime
27.Nd check ELF runtime attributes
28.Sh SYNOPSIS
29.Nm check_rtime
30.Op Fl imosv
31.Op Fl D Ar depfile | Fl d depdir
32.Op Fl E Ar errfile
33.Op Fl e Ar exfile
34.Op Fl f Ar listfile
35.Op Fl I Ar infofile
36.Op Fl w Ar outdir
37.Ar file | dir ...
38.Sh DESCRIPTION
39.Nm check_rtime
40attempts to check a number of ELF runtime attributes
41for consistency with common build rules.
42These checks involve running
43.Xr ldd 1
44and
45.Xr elfdump 1
46against a family of dynamic objects.
47A dynamic object can be defined explicitly as a
48.Ar file
49or multiple dynamic objects can be located under the directory
50.Ar dir .
51.Pp
52.Nm check_rtime
53is typically called from
54.Xr nightly 1ONBLD
55when the
56.Fl r
57option is in effect.
58In this case the objects under
59the associated
60.Em proto area
61.Pq Ev $ROOT
62are checked.
63.Nm check_rtime
64can also be run standalone against any set of objects.
65.Pp
66.Nm check_rtime
67uses
68.Xr  ldd 1
69to verify dependencies.
70This implies that by default any object inspected will bind to its dependencies
71as they are found in the
72.Em underlying system .
73Use of the
74.Fl D ,
75.Fl d
76option, or the existence of the environment variables
77.Ev $CODEMGR_WS
78or
79.Ev $ROOT
80instruct
81.Nm check_rtime
82to establish an alternative dependency mapping using
83runtime configuration files generated with
84.Xr crle 1 .
85.Pp
86.Nm check_rtime
87uses
88.Xr ldd 1
89to completely relocate any dynamic object and thus detect missing
90dependencies, unsatisfied symbol relocations, unused and unreferenced
91dependencies.
92These checks are carried out for the following reasons:
93.Bl -bullet
94.It
95An object that cannot find its dependencies may fail to load
96at runtime.
97This error condition often goes unnoticed because the existing use of the
98object is as a dependency itself, and the objects' dependencies are already
99satisfied by the caller.
100However, if the object itself is unable to satisfy its dependencies, its use
101in new environments may be compromised.
102.Pp
103A missing or erroneous
104.Em runpath
105is the typical reason why an object can not locate its dependencies.
106Use of the link-editors
107.Fl zdefs
108option when building a shared object ensures required dependencies are
109established.
110This flag is inherited from
111.Dv $(DYNFLAGS)
112in
113.Pa lib/Makefile.lib .
114Missing dependencies are displayed as:
115.Pp
116.Dl foo: bar.so.1 => (file not found)  <no -zdefs?>
117.It
118Unsatisfied symbol relocations indicate that some thread of
119execution through the object will fail when it is unable to
120locate a referenced symbol.
121.Pp
122A missing, or mismatched version of a dependency is the typical
123reason for unsatisfied symbol relocations (see missing dependency
124discussion above). Unsatisfied symbol relocations are displayed as:
125.Pp
126.Dl foo: symbol not found: bar  <no -zdefs?>
127.Pp
128Note: Shared objects can make reference to symbol definitions
129that are expected to be defined by the caller.
130To indicate that such symbols are not undefined in the usual sense, you must
131specify these symbols in a
132.Em mapfile ,
133using the
134.Va EXTERN
135or
136.Va PARENT
137symbol attributes.
138Without these symbol attributes,
139.Xr ldd 1
140is unable to determine the symbols special nature, and
141.Nm check_rtime
142will report these symbols as undefined.
143.It
144Unused dependencies are wasteful at runtime, as they take time to
145load and relocate, but will not be used by the calling object.
146They also result in unnecessary processing at link-edit time.
147.Pp
148Dependency lists (typically defined via
149.Dv $(LDLIBS) )
150that have been copy and pasted
151between
152.Pa Makefiles
153without verifying their need, are a typicalreason why unused dependencies
154exist.
155Unused dependencies are displayed as:
156.Pp
157.Dl foo: unused object=bar.so.1  <remove lib or -zignore?>
158.It
159Unreferenced dependencies are also wasteful at runtime, although not
160to the extent of unused dependencies.
161They also result in unnecessary processing at link-edit time.
162.Pp
163Unreferenced dependency removal guards against a dependency becoming
164unused when combined with
165different objects, or as the other object dependencies evolve.
166Unreferenced dependencies are displayed as:
167.Bd -literal
168foo: unreferenced object=bar.so.1;  \\
169    unused dependency of libfoo.so.1  \\
170    <remove lib or -zignore?>
171.Ed
172.Pp
173See also the section
174.Sx ENVIRONMENT VARIABLES .
175.It
176Unused search paths are wasteful at runtime.
177Unused search paths are displayed as:
178.Bd -literal
179foo: unused search path=/usr/foo/lib  \\
180    (RUNPATH/RPATH from file libfoo.so.1)  \\
181    <remove search path?>
182.Ed
183.El
184.Pp
185.Nm check_rtime
186uses
187.Xr elfdump 1
188to look for a concatenated relocation section in shared objects, the existence
189of text relocations, whether debugging or symbol table information exists,
190whether applications have a non-executable stack defined, duplicate entries in
191the symbol sorting sections, and for direct bindings.
192These checks are carried out for the following reasons:
193.Bl -bullet
194.It
195A concatenated relocation section
196.Pq Em .SUNW_reloc
197provides optimal symbol table access at runtime, and thus reduces the overhead
198of relocating the shared object.
199In past releases, the link-edit of a dynamic object with the
200.Fl z Ar combreloc
201option was required to generate a combined relocation section.
202However, with the integration of 6642769, this section combination is a default behavior of
203the link-editor.
204.Pp
205In past releases, not inheriting
206.Dv $(DYNFLAGS)
207from
208.Pa lib/Makefile.lib
209was the typical reason for not having a concatenated relocation section.
210The misguided use of the
211.Fl z Ar nocombreloc
212option will also prevent the creation of a concatenated relocation section.
213A missing concatenated relocation section is displayed as:
214.Pp
215.Dl foo: .SUNW_reloc section missing  <no -zcombreloc?>
216.It
217Text relocations result in impure text segments.
218As text segments are typically read-only, they can be shared between numerous
219processes.
220If they must be updated as part of the relocation then the updated pages
221become unsharable and swap space must be allocated to back these pages.
222These events consume unnecessary system resources and reduce overall system
223performance.
224.Pp
225Not inheriting the
226.Dv $(PICS)
227rules from
228.Pa lib/Makefile.lib
229is the typical reason for having non-pic code in shared objects.
230Text relocations are displayed as:
231.Pp
232.Dl foo: TEXTREL .dynamic tag  <no -fpic?>
233.It
234Debugging information is unnecessary in released objects.
235Although extensive when compiled
236.Fl g ,
237small quantities of debugging information are stored in
238.Em .stabs
239sections under normal compilations.
240This debugging information is geared towards aiding debuggers locate
241relocatable objects associated with the dynamic objects being debugged.
242As relocatable objects aren't made available as part of a software release
243this information has no use.
244.Pp
245Not inheriting the correct
246.Dv $(LDFLAGS)
247from
248.Pa cmd/Makefile.cmd
249.Pq which asserts Fl s
250or
251.Dv $(POST_PROCESS_SO)
252.Pq which asserts Ic strip -x
253are typical reasons for not removing debugging information.
254Note, removal of debugging information is only enabled
255for release builds.
256The existence of debugging information is displayed as:
257.Bd -literal
258foo: debugging sections should be deleted  \\
259    <no strip -x?>
260.Ed
261.It
262All objects should retain their full
263.Em .symtab
264symbol table.
265Although this consumes disk space, it provides for more extensive stack
266tracing when debugging user applications.
267.Pp
268Hard coding a
269.Fl s
270flag with
271.Dv $(LDFLAGS) or
272.Dv $(DYNFLAGS)
273is the typical reason for symbol tables being removed.
274Objects that do not contain a symbol table are displayed as:
275.Bd -literal
276foo.so.1: symbol table should not be stripped  \\
277    <remove -s?>
278.Ed
279.It
280Applications should have a non-executable stack defined to make
281them less vulnerable to buffer overflow attacks.
282.Pp
283Not inheriting the
284.Dv $(LDFLAGS)
285macro in
286.Pa cmd/Makefile.cmd
287is the typical reason for not having a non-executable stack definition.
288Applications without this definition are displayed as:
289.Bd -literal
290foo: application requires non-executable stack \\
291	<no -Mmapfile_noexstk?>
292.Ed
293.It
294x86 applications should have a non-executable data segment defined to make
295them less vulnerable to buffer overflow attacks.
296.Pp
297Not inheriting the
298.Dv $(LDFLAGS)
299macro in
300.Pa cmd/Makefile.cmd
301is the typical reason for not having a non-executable data definition.
302Applications without this definition are displayed as:
303.Bd -literal
304foo: application requires non-executable data \\
305	<no -Mmapfile_noexdata?>
306.Ed
307.It
308Solaris ELF files contain symbol sort sections used by DTrace to
309map addresses in memory to the related function or variable symbols.
310There are two such sections,
311.Em .SUNW_dynsymsort
312for regular symbols, and
313.Em .SUNW_dyntlssort
314for thread-local symbols.
315To ensure that the best names are shown for each such address, and that the
316same name is given across Solaris releases,
317.Nm check_rtime
318enforces the rule that only one symbol can appear in the sort sections for
319any given address.
320There are two common ways in which multiple symbols
321or a given address occur in the ON distribution.
322The first is from code written in assembly language.
323The second is as a result of using
324.Ic #pragma weak
325in C to create weak symbols.
326The best solution to this situation is to modify the code to avoid symbol
327aliasing.
328Alternatively, the
329.Va NODYNSORT
330mapfile attribute can be used to eliminate the unwanted symbol.
331.Pp
332Duplicate entries in a symbol sort section are
333displayed in one of the following ways, depending on
334whether the section is for regular or thread-local symbols:
335.Bd -literal
336foo: .SUNW_dynsymsort: duplicate ADDRESS: sym1, sym2
337foo: .SUNW_dyntlssort: duplicate OFFSET: sym1, sym2
338.Ed
339.It
340illumos dynamic ELF objects are expected to employ direct bindings whenever
341feasible.
342This runtime binding technique helps to avoid accidental interposition
343problems, and provides a more optimal runtime symbol search model.
344.Pp
345Not inheriting the correct
346.Dv $(LDFLAGS) from
347.Pa cmd/Makefile.cmd ,
348or the correct
349.Dv $(DYNFLAGS)
350from
351.Pa lib/Makefile.lib ,
352are the typical reasons for not enabling direct bindings.
353Dynamic objects that do not contain direct binding information are displayed
354as:
355.Bd -literal
356foo: object has no direct bindings \\
357	<no -B direct or -z direct?>
358.Ed
359.El
360.Pp
361.Nm check_rtime
362also
363uses
364.Xr elfdump 1
365to display useful dynamic entry information under the
366.Fl -i
367option.
368This doesn't necessarily indicate an error condition, but
369provides information that is often useful for gatekeepers to track
370changes in a release.
371Presently the information listed is:
372.Bl -bullet
373.It
374Runpaths are printed for any dynamic object.
375This is a historic sanity check to insure compiler supplied runpaths
376(typically from
377.Nm CC )
378are not recorded in any objects.
379Runpaths are displayed as:
380.Pp
381.Dl foo: RPATH=/usr/bar/lib
382.It
383Needed dependencies are printed for any dynamic object.
384In the freeware world this often helps the introducer of a new
385shared object discover that an existing binary has become its
386consumer, and thus that binaries package dependencies may require updating.
387Dependencies are printed as:
388.Pp
389.Dl foo: NEEDED=bar.so.1
390.It
391Dependencies may be marked as forbidden
392.Pq see Sx EXCEPTION FILE FORMAT
393this allows the build to warn should people use them accidentally.
394Forbidden dependencies are printed as:
395.Pp
396.Dl foo: NEEDED=bar.so.1  <forbidden dependency, missing -nodefaultlibs?>
397.El
398.Pp
399.Nm check_rtime
400uses
401.Xr mcs 1
402to inspect an object's
403.Em .comment
404section.
405During development, this section contains numerous file identifiers
406marked with the tag
407.Qq @(#) .
408For release builds these sections are deleted and rewritten under control of
409the
410.Dv $(POST_PROCESS)
411macro to produce a common release identifier.
412This identifier typically consists of three lines including a single comment
413starting with the string
414.Qq @(#) SunOS .
415If this common identifier isn't found the following diagnostic is generated:
416.Pp
417.Dl foo: non-conforming mcs(1) comment  <no $(POST_PROCESS)?>
418.Pp
419.Nm check_rtime
420uses
421.Xr pvs 1
422to display version definitions under the
423.Fl v
424option.
425Each symbol defined by the object is shown along with the version it belongs to.
426Changes to the symbols defined by an object, or the versions they belong to,
427do not necessarily indicate an error condition, but
428provides information that is often useful for gatekeepers to track
429changes in a release.
430.Pp
431.Nm check_rtime
432uses
433.Xr elfedit 1
434to verify that relocatable objects which seem likely to be kernel modules were
435linked with the
436.Fl z Ar type=kmod
437flag.
438.Sh OPTIONS
439The following options are supported:
440.Bl -tag -width indent
441.It Fl D Ar depfile
442Use
443.Ar depfile
444to generate an alternative dependency mapping.
445.Ar depfile
446must be created by
447.Ic find_elf -r .
448The
449.Fl D
450and
451.Fl d
452options are mutually exclusive.
453.It Fl d Ar depfile
454Use
455.Ar depdir
456to generate an alternative dependency mapping.
457.Xr find_elf 1ONBLD
458is used to locate the ELF sharable objects for which alternative mappings are
459required.
460The
461.Fl D
462and
463.Fl d
464options are mutually exclusive.
465.It Fl E Ar errfile
466Direct error messages for the analyzed objects to
467.Ar errfile
468instead of stdout.
469.It Fl e Ar exfile
470An exception file is used to exclude objects from
471the usual rules.
472See
473.Sx EXCEPTION FILE FORMAT .
474.It Fl f Ar listfile
475Normally,
476.Ic interface_check
477runs
478.Ic find_elf
479to locate the ELF objects to analyze.
480The
481.Fl f
482option can be used to instead provide a file containing the list of objects to
483analyze, in the format produced by
484.Ic find_elf -r .
485.It Fl I Ar infofile
486Direct informational messages (
487.Fl i ,
488and
489.Fl v
490options) for the analyzed objects to
491.Ar infofile
492instead of stdout.
493.It Fl i
494Provide dynamic entry information.
495Presently only dependencies and runpaths are printed.
496.It Fl m
497Enable
498.Xr mcs 1
499checking.
500.It Fl o
501Produce a one-line output for each condition discovered, prefixed
502by the objects name.
503This output style is more terse, but is more appropriate for sorting and
504diffing with previous build results.
505.It Fl s
506Determine whether
507.Em .stabs
508sections exist.
509.It Fl v
510Provide version definition information.
511Each symbol defined by the object is printed along with the version it is
512assigned to.
513.It Fl w Ar outdir
514Interpret the paths of all input and output files relative to
515.Ar outdir .
516.El
517.Sh EXCEPTION FILE FORMAT
518Exceptions to the rules enforced by
519.Nm check_rtime
520are specified using an exception file.
521The
522.Fl -e
523option is used to specify an explicit exception file.
524Otherwise, if used in an activated workspace, the default exception file is
525.Pa $CODEMGR_WS/exception_list/check_rtime
526if that file exists.
527If not used in an activated workspace, or if
528.Pa $CODEMGR_WS/exception_list/check_rtime
529does not exist,
530.Nm check_rtime
531will use
532.Pa /opt/onbld/etc/exception_list/check_rtime
533as a fallback default exception file.
534.Pp
535To run
536.Nm check_rtime
537without applying exceptions, specify
538.Fl e
539with a value of
540.Pa /dev/null .
541.Pp
542A
543.Ql #
544character at the beginning of a line, or at any point in
545a line when preceded by whitespace, introduces a comment.
546Empty lines, and lines containing only comments, are ignored by
547.Nm check_rtime .
548Exceptions are specified as space separated keyword, and
549.Xr perl 1
550regular expression:
551.Pp
552.Dl keyword  perl-regex
553.Pp
554Since whitespace is used as a separator, the regular
555expression cannot itself contain whitespace.
556Use of the
557.Ql \es
558character class to represent whitespace within the regular expression is
559recommended.
560.Pp
561Before the perl regular expression is used, constructs of the form
562.Em MACH(dir)
563are expanded into a regular expression that matches the directory given, as
564well as any 64-bit architecture subdirectory that might be present
565(i.e. amd64, sparcv9). For instance,
566.Em MACH(lib)
567will match any of the following:
568.Bl -tag -width indent
569.It Pa lib
570.It Pa lib/amd64
571.It Pa lib/sparcv9
572.El
573.Pp
574The exceptions understood by
575.Nm check_rtime
576are:
577.Bl -tag -width indent
578.It EXEC_DATA
579Executables that are not required to have non-executable writable
580data segments
581.It EXEC_STACK
582Executables that are not required to have a non-executable stack
583.It KMOD
584Objects that looks like kernel modules but don't have to be linked with the
585.Fl z Ar type=kmod
586flag.
587.It NOCRLEALT
588Objects that should be skipped when building the alternative dependency
589mapping via the
590.Fl d
591option.
592.It NODIRECT
593Directories and files that are allowed to have no direct bound symbols.
594.It NOSYMSORT
595Files for which we skip checking of duplicate addresses in the
596symbol sort sections.
597.It OLDDEP
598Objects that used to contain system functionality that has since
599migrated to libc.
600We preserve these libraries as pure filters for backward compatibility but
601nothing needs to link to them.
602.It SKIP
603Directories and/or individual objects to skip.
604Note that SKIP should be a last resort, used only when one of the other
605exceptions will not suffice.
606.It STAB
607Objects that are allowed to contain debugging information (stabs).
608.It TEXTREL
609Objects for which we allow relocations to the text segment.
610.It UNREF_OBJ
611Objects that are allowed to be unreferenced.
612.It UNDEF_REF
613Objects that are allowed undefined references.
614.It UNUSED_DEPS
615Objects that are allowed to have unused dependencies.
616.It UNUSED_OBJ
617Objects that are always allowed to be unused dependencies.
618.It UNUSED_RPATH
619Objects that are allowed to have unused runpath directories.
620.It FORBIDDEN
621Specifies that dependencies on a given object are forbidden.
622.It FORBIDDEN_DEP
623Specifies that a given object is permitted a forbidden dependency.
624.El
625.Sh ALTERNATIVE DEPENDENCY MAPPING
626.Nm check_rtime
627was primarily designed to process a nightly builds
628.Ev $ROOT
629hierarchy.
630It is often the case that objects within this hierarchy must bind to
631dependencies within the same hierarchy to satisfy their requirements.
632.Pp
633To achieve this,
634.Nm check_rtime
635uses the shared objects specified with the
636.Fl D
637or
638.Fl d
639options.
640If neither option is specified, and the
641.Ev $CODEMGR_WS
642and
643.Ev $ROOT
644environment variables are defined, the proto area for the workspace is
645used.
646The objects found are used to create runtime configuration files via
647.Xr crle 1 ,
648that establish the new shared objects as alternatives to their underlying
649system location.
650.Nm check_rtime
651passes these configuration files as
652.Ev LD_CONFIG
653environment variable settings to
654.Xr ldd 1
655using its
656.Fl -e
657option.
658.Pp
659The effect of these configuration files is that the execution of an
660object under
661.Xr ldd 1
662will bind to the dependencies defined as alternatives.
663Simply put, an object inspected in the
664.Pa proto
665area will bind to its dependencies found in the
666.Pa proto
667area.
668Dependencies that have no alternative mapping will continue to bind to the
669underlying system.
670.Sh ENVIRONMENT VARIABLES
671When the
672.Fl D
673or
674.Fl d
675option isn't in use,
676.Nm check_rtime
677uses the following environment variables to
678establish an alternative dependency mapping:
679.Bl -tag -width indent
680.It Ev CODEMGR_WS
681The root of your workspace, which is the directory
682containing
683.Pa .git .
684Existence of this environment variable indicates that
685.Ev $ROOT
686should be investigated.
687.It Ev ROOT
688Root of the
689.Pa proto
690area of your workspace.
691Any shared objects under this directory will be used to establish an
692alternative dependency mapping.
693.El
694If
695.Xr ldd 1
696supports the
697.Fl U
698option, it will be used to determine any unreferenced dependencies.
699Otherwise
700.Xr ldd 1
701uses the older
702.Fl u
703option which only detects unused references.
704If the following environment variable exists, and indicates an earlier release
705than \fB5.10\fP then
706.Xr ldd 1
707also falls back to using the
708.Fl u
709option.
710.Bl -tag -width indent
711.It Ev RELEASE
712The release version number of the environment being built.
713.El
714.Sh ERROR CONDITIONS
715Inspection of an object with
716.Xr ldd 1
717assumes it is compatible with the machine on which
718.Nm check_rtime
719is being run.
720Incompatible objects such as a 64-bit object encountered on a 32-bit system,
721or an i386 object encountered on a sparc system, can not be fully inspected.
722These objects are displayed as:
723.Pp
724.Dl foo: has wrong class or data encoding
725.Sh FILES
726.Bl -tag -width indent
727.It Pa $CODEMGR_WS/exception_list/check_rtime
728.It Pa /opt/onbld/etc/exception_list/check_rtime
729.El
730.Sh SEE ALSO
731.Xr crle 1 ,
732.Xr elfdump 1 ,
733.Xr ld.so.1 1 ,
734.Xr ldd 1 ,
735.Xr mcs 1 ,
736.Xr find_elf 1ONBLD
737