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