PROBLEM: (QAR 72957) (Patch ID: OSF500-012) ******** The problem is that any kernel that is larger than 4 MB and linked with the old linker will have the etext and _etext symbols pointing to the wrong place. To see this problem: odump -hv /vmunix This gives you output such as the following: ***SECTION HEADER*** Name Paddr Vaddr Size Scnptr Relptr Lnnoptr Nreloc Nlnno Flags /vmunix: .text 0xfffffc0000230000 0xfffffc0000230000 0x0000000000505160 0x0000000000000270 0x0000000000000000 0x0000000000000000 0 0 REG, TEXT .data 0xfffffc000075c770 0xfffffc000075c770 0x00000000000fe420 0x000000000052c9e0 0x0000000000000000 0x0000000000000000 0 0 REG, DATA .rdata 0xfffffc0000758bb0 0xfffffc0000758bb0 0x0000000000003bc0 0x0000000000528e20 0x0000000000000000 0x0000000000000000 0 0 REG, RDATA .rconst 0xfffffc0000735160 0xfffffc0000735160 0x0000000000023a50 0x00000000005053d0 0x0000000000000000 0x0000000000000000 0 0 REG, RCONST (........etc....) If you add the Size of the .text section to the Vaddr of the .text section, this value should be where etext and _etext point. The preceding example produces the following values: 0xfffffc0000230000 + 0x0000000000505160 = 0xfffffc0000735160 (vaddr) + (Size) = (etext) You could then use the following command to look at the symbol in your vmunix kernel: nm -x /vmunix | grep _etext You might get output such as this: _etext | 0xfffffc0000740250 | T | 0x00000000000008 Note that the address 0xfffffc0000740250 is in the middle of .rconst, instead of the expected 0xfffffc0000735160. PROBLEM: (QAR 73776) ******** When using the -input flag with the ld(1) command, the ld(1) command core dumps if the line in the file exceeds 1024 characters. The immediate problem is that this limit is not checked. Also, this limit is not documented in the ld(1) man pages. PROBLEM: (QAR 73776) ******** The use of the line continuation character (backslash) gets ignored and the continued line is interpreted as another argument to the linker. PROBLEM: (QAR 74693) ******** The linker may fail with a message similar to the following when processing a large (multi-GOT) image in the presence of -om and -shared or -om and -call-shared options: ld: Object file format error in: t7.o: relocate: extern lita entries cannot have non-zero offsets; 'sub7_0' has 0x825ae4) *** Cannot open file /tmp/ctmomaavuza (No such file or directory) *** Exit 1 Stop. $ PROBLEM: (QAR 74694) ******** The OM post-link optimizer can occasionally fail with the following message when processing a large (multi-GOT) image in the presence of -call-shared or -shared options: om: fast access range error *** Exit 1 Stop. $ PROBLEM: (QAR 73386) ******** The linker symbol merging logic was not properly handling symbols when a scTlsUndefined symbol was the first reference to a particular symbol. This would lead to 'multiply defined' symbol errors and incorrect behavior. In addition, if the scTlsUndefined symbol was never resolved, the linker would terminate with an assertion that there were relocations against an illegal symbol class. PROBLEM: (74693, 76358, 76821, 78218, 78470, 78471) (PATCH ID: OSF500-190) ******** There were three different problems addressed with this fix. Problem 1: When compiling with -call_shared -om with programs with very large numbers of external symbols, an error message such as this might occur out of the linker (ld): cc -o mgot.om -om -call_shared t*.o ld: Object file format error in: t7.o: relocate: extern lita entries cannot have non-zero offsets; 'sub7_0' has 0x825ae4) Problem 2: When compiling with -call_shared -om with programs with very large numbers of local symbols, an error message such as this might occur out of the linker (ld): ld: assertion failed at ../../../../../../src/usr/ccs/bin/ld/relocate.c line 2909 Problem 3: When linking call_shared and including a library twice on the link line with another library in between, there would be unresolved references reported. However, just including the library once, after the intervening library, would succeed in linking. Here is an example of this: % ls a.c libgcc.a % cat a.c main() { __eprintf(); /* __eprintf is defined in libgcc.a */ } % cc -c a.c -o a.o % ld -call_shared /usr/lib/cmplrs/cc/crt0.o a.o -L. -lc -lgcc -lc ld: Unresolved: _iob fprintf fflush abort # However, if one modifies the link to put -lgcc before -lc and # includes -lc only once on the link line, then the link works fine. % ld -call_shared /usr/lib/cmplrs/cc/crt0.o a.o -L. -lgcc -lc PROBLEM: (77290, 78669, 82501) (PATCH ID: OSF500-344) ******** PROBLEM: Using the -f switch with the linker (ld) produces link errors such as: ld: /usr/.../libc.a(file.o): write_outbuf: Not enuf room in bfr f_outbuf? nbytes(1264) > left(0) PROBLEM: Any switch that begins with -f and is not a legal switch to the linker gets interpreted to mean -f. For example '-funfun' is taken to mean -f. PROBLEM: (82808, 87682) (PATCH ID: OSF500-348) ******** This patch modifies the linker's symbol resolution to enable it to recognize when a reference to a symbol defined in a shared library is replaced by a symbol defined in an object file or archive. Previously, the linker failed to handle this replacement consistently when a symbol was defined by both a shared library and an object or archive that followed it on the linker command line. This would frequently lead to failed links reporting "multiply defined symbol" errors. This patch also modifies the linker to cause it to rescan shared libraries before reporting unresolved symbols. Symbols are sometimes added to the linker's list of unresolved symbols because the references to those symbols appear in object files or archives that are linked in after the shared libraries in which the symbols are defined. This final scan allows all symbol definitions to be recognized, and no symbols are misreported as being unresolved. In the following example, if the symbol "a" is defined in b.so and c.o and referenced in a.o, then without this patch, the linker behavior would be: cc a.o b.so c.o -rpath . ld: c.o: a: multiply defined With this patch, the linker will successfully perform the link using the definition of the symbol "a" from c.o. Using the following example for the second problem described, if the symbol "a" were defined in b.so and referenced from c.o, the linker would report an unresolved symbol error. ld -call_shared /usr/lib/cmplrs/cc/crt0.o a.o b.so -lc c.o ld: Unresolved: a With this patch, the linker will successfully perform the link. Last, this patch fixes a problem where the linker may incorrectly optimize the "jsr" Alpha instruction when linking large applications at -O2 or higher. This could result in an incorrect function call. The likelihood of encountering this problem is extremely rare because numerous low-level conditions must also be true during the link. PROBLEM: (78237) (PATCH ID: OSF500-364) ******** This problem occurs if a program references the linker defined symbol _fpdata and the linker does not use this symbol. A case where this might be seen is the case of a program in which no exception handling is being used. An executable with this problem would not get any errors linking, but if you did the following command on the executable: nm -xv myprog.exe | grep fpdata you would get the following output: _fpdata | 0x00000000000000 | U | 0x00000000000000 Also, doing this: odump -jf myprog.exe | grep -i null you would see a line such as the following (with a different address): 0x120006f28 REFQUAD After the patch, you will not see the null using the odump command, and using the nm command you will get something like this: _fpdata | 0x00000000000000 | A | 0x00000000000008 If the linker makes use of the _fpdata symbol, then this problem does not arise.