The following warnings are usual when linking Oracle database software on Solaris:
ld: warning: mapfile: text segment: section '.text%rwssid' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kdimod0' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kss_set_proc' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kturrur' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kturru' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kcbism' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kssocbg' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kkoadsTimeLimitFromSrc' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%dbglWriteLogMsgtoDisk' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%qosdGetTb4Find' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kkorrio' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%ztcrbp' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%ztcrbh' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kdmrExeKtsjTask' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kokl_pdbaware_kdlf_copy' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kkeapr' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kkjex1s' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kkjcjchk' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kudmrOpenCBK' does not appear in any input file
ld: warning: mapfile: text segment: section '.text%kssdmp1' does not appear in any input fileIn this article I’ll explain their origin and why they can normally be safely ignored.
The linker complained that it couldn’t find a section, i.e. function, in any of the input objects files.
For example, the function rwssid indeed isn’t contained in the oracle 19c binary:
nm /u00/oracle/orabase/product/19.12.0.0.210720_a/bin/oracle | grep rwssidBut where does the linker get the idea about non-existing functions?
They are configured in the mapfile /u00/oracle/orabase/product/19.12.0.0.210720_a/rdbms/lib/oracle.map:
grep rwssid $ORACLE_HOME/rdbms/lib/oracle.map
text: .text%rwssid;The oracle.map is specified as a mapfile when linking the oracle executable:
/usr/ccs/bin/ld -o /u00/oracle/orabase/product/19.12.0.0.210720_a/rdbms/lib/oracle ... -M /u00/oracle/orabase/product/19.12.0.0.210720_a/rdbms/lib/oracle.map ...Let’s inspect the mapfile:
text = LOAD ?RXO;
text: .text%main;
text: .text%ssthrdmain;
text: .text%opimai_real;
text: .text%sou2o;
text: .text%opidrv;
text: .text%opiodr;
text: .text%opiino;
text: .text%opitsk;
text: .text%ttcpip;
text: .text%opiexe;
text: .text%kkxexe;
text: .text%peicnt;
text: .text%plsql_run;
text: .text%pfrrun;
text: .text%pfrrun_no_tool;
...The first declaration LOAD ?RXO tells the linker how to create the output file. RX specifies executable and readable output file. The ?O flag forces the ordering of the functions as specified later in the mapfile. Without this flag, the functions in the binary file would have been ordered as they appear in the source file.
We can see that the functions in the executable are indeed sorted according to the mapfile:
nm -vP oracle
...
main T 627eef0 b8
ssthrdmain T 627efc0 65a
opimai_real T 627f630 221
sou2o T 627f870 108
opidrv T 627f990 930
opiodr T 62802d0 40a7
opiino T 6284390 f4c
opitsk T 62852f0 4a24
ttcpip T 6289d30 4790
opiexe T 628e4d0 ef68
kkxexe T 629d450 10ec
peicnt T 629e550 115b
plsql_run T 629f6c0 1454
pfrrun T 62a0b30 2778
pfrrun_no_tool t 62a32c0 71
...( -v flag prevents sorting by function names; -P generates a less verbose output.)
But why are non-existing functions specified in the mapfile?
Those functions used to exist in previous releases, but developers forgot to update the mapfile after they removed them.
For example, the function rwssid disappeared somewhere between releases 12.2 and 19c:
nm -P /u00/oracle/orabase/product/12.2.0.1.180116_b/bin/oracle | grep rwssid
rwssid T 99b2bb0 32The oracle binary is intact – such warnings can be safely ignored.
Updates
September 25, 2021
The article elicited an interesting discussion on Twitter.
Find the main points below.
Reason
Frits Hoogland suggested that the ordering might be an optimization technique to keep jumps shorter.
Indeed, more generic functions, like main, ssthrdmain, opimai_real, sou2o, opi*, etc., that are generally executed less frequently and appear higher up on the stack, come first.
Roger MacNicol confirmed that the purpose of ordering is to reduce cache and iTLB misses.
Linux
Interestingly, there’s isn’t such ordering on Linux:
nm -vP oracle > /tmp/nm.out
...
main T 0000000000db77c0 0000000000000130
opimai_real T 0000000000db78f0 00000000000001c0
opimai_init t 0000000000db7ab0 0000000000000500
kudmiini T 0000000000db7fc0 0000000000000580
kudmiparms T 0000000000db8540 0000000000001ac0
kudmnli t 0000000000dba000 0000000000000580
kudmgrf t 0000000000dba580 0000000000000ef0
kudmgfa t 0000000000dbb470 0000000000000220
kudmgfl t 0000000000dbb690 00000000000022d0
kudmignme T 0000000000dbd960 0000000000000040
kudmgds t 0000000000dbd9a0 00000000000003e0
kudmppcval t 0000000000dbdd90 0000000000000030
kudmppcste t 0000000000dbddc0 0000000000000040
kudmppparse T 0000000000dbde00 0000000000000350
kudmppz t 0000000000dbe150 0000000000000030
kudmppk t 0000000000dbe180 0000000000000290
...