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