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