PROBLEM: (QAR 72957) (Patch ID: OSF440-139) ******** 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 74845, 74845, 70308, 73919) (Patch ID: OSF440-230, OSF440-231) An NHD2 installation will modify /usr/ccs/lib/cmplrs/cc/ld (system linker) and the /osf_boot file. This patch provides the same update to the linker and osf_boot file that the NHD2 installation provides. It is being delivered here so that an installation of this patch kit does not undo the linker and osf_boot changes supplied with the NHD2 installation. PROBLEM: (QAR 73776) (Patch ID: OSF440-195) ******** 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) (Patch ID: OSF440-195) ******** The use of the line continuation character (backslash) gets ignored and the continued line is interpreted as another argument to the linker. PROBLEM: (77577) (PATCH ID: OSF440-350) ******** This new version os osf_boot provides more space for NHD installations to load sysconfigtab snippets during bootlink. Previous versions would fail with the message: osf_boot: Not enough space to add '................. This message is produced after the bootlink is complete, but before the system starts the kernel. PROBLEM: (76358, 76821) (PATCH ID: OSF440-376) ******** 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: (80175, 80012) (PATCH ID: OSF440-475) ******** This patch fixes a problem in which the bootlink can fail on alphastations 600, 600A, 500/400. PROBLEM: (87682) (PATCH ID: OSF440-616) ******** 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: (77290, 78669, 82501) (PATCH ID: OSF440-527) ******** 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: (78237) (PATCH ID: OSF440-539) ******** 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 After the patch, 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. PROBLEM: (82808) (PATCH ID: OSF440-533) ******** 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.