PROBLEM: (QAR 58033) (Patch ID: OSF425-217) ******** Programs linked -call_shared and linked with libc.a may fail to load. The loader will be in an infinite loop with no visible output. One way to determine if the loader is hanging as a result of the problem fixed by this patch is to set the _RLD_ARGS environment variable to "-debug symbol -log logfile" and see if the logfile shows an endless loop with entries of the following style: 358:main: /sbin/loader: resolve_symbol: found strong symbol for _foo -- _foo(89307) 358:main: /sbin/loader: resolve_symbol: resolving _foo from libtemp.so, with hash value 0x5d029d6 When this problem occurs, the name of the symbol in the above log entries will not change. There is no easy way to duplicate this problem. It involves a combination of executables with multiple GOT entries and weak symbols. PROBLEM: (QAR 56896,SPR HPAQA259P) (Patch ID: OSF425-217) ******** This fix allows the loader to report the name of unresolved symbols from libraries which are opened with dlopen() calls. Previously when this situation occurred, the loader would report the following error: % ./a.out Unable to load shared library file: dlopen: Unresolved symbols Error 0 The new loader behavior is to report the symbol name and the library name, as follows: % ./a.out Unable to load shared library file: Unresolved symbol in ./hw.so: foo Error 0 This problem can be reproduced by having a program use dlopen() to open a library with unresolved symbols in it. PROBLEM: (QAR 57068) (Patch ID: OSF425-218) ******** This patch fixes a problem where the linker might crash when printing out lengthy error diagnostics. PROBLEM: (QAR 60767) (Patch ID: OSF425-263) ******** This patch is a fix for a linker bug that could cause valid conflict symbols to not be recorded in the linked executable's conflict section. The following conditions are necessary to reproduce the problem fixed by this patch. - The application is linked -call_shared. - The application is large enough to require more than one Global Offset Table (GOT) in the executable. Multiple occur when the number of referenced external symbols he application exceeds 8190. - The user adds a symbol to their application which has the same name as a symbol in one of the shared libraries used by the application. For example, if a user linked their own malloc routine into an application, the libc malloc routine may be used instead. If you think you're experiencing this problem, one way to quickly verify it is to set the _RLD_ARGS environment variable to "-force checksum". Setting this will force the loader to resolve all symbols and ensure that the proper symbols are used. Another option to determine if you're experiencing this problem is to dump the conflict symbol table from the linked executable. This is performed with "odump -Dc application_name". If you've added a symbol to your application and the symbol also exists in one of the shared libraries used by the application, then the symbol should be listed in the conflict symbol table. If it isn't, this patch may be required. PROBLEM: (QAR 56987) (Patch ID: OSF425-043) ******** When the -fast switch is specified on the command line, the cc command (driver) instructs the c compiler to create a single object file for all of the .c files specified. If the -c switch is also included, this one large object file remains after the compilation completes. When these two switches are specified, and the -compress switch is also specified asking for a compressed object, the cc driver fails to supply its call to objZ (to do the compression) with the object file name that is being used for the final object file output. Without this patch, when these switches are used in combination, the call to objZ to compress the object file fails with a "usage" error since no object file is specified for the compression. PROBLEM: (QAR 58430) (Patch ID: OSF425-291) ******** The current preferred mechanism for passing command line switches to a given phase of compilation via cc is with the -W switch. The cc driver uses the character following the "W" to direct the switch following it to the appropriate phase. This patch addresses a problem that occurs when trying to pass a '-input filename' switch to ld (the linker) through cc. The file that 'filename' refers to contains lines that are interpreted by ld as if they were included on the actual command line. For example: cc test.o -Wl,-input,ldinput where: cat ldinput sub.o This cc command invokes ld, passing test.o and "-input ldinput". ld opens the file "ldinput" and adds sub.o to its own command line. The problem occurs when the contents of a file passed in this manner are position dependent when presented to ld. Specifically, cc puts arguments passed via Wl on the command line first, followed by any switches or object files entered by the user on the cc command line that are meant for ld. This includes the specification of /usr/lib/cmplrs/cc/crt0.o, which is the transfer point for all executables (the place where control is transferred when a program is loaded). cc always adds this to the ld command line when an executable is being created. The ld command line created by cc in the above example looks like this: cc -v test.o -Wl,-input,ldinput ld -input ldinput -g0 -O1 -call_shared /usr/lib/cmplrs/cc/crt0.o test.o -lc Notice the placement of "-input ldinput" on the ld command line. When linking an executable, the linker lays out the code in the order in which it sees the input .o files. The very first address in the text section will be the transfer address, or entry point, for the program. This MUST BE crt0.o. The executable created by the command line above produces a transfer address point in sub.o, and ultimately a segmentation fault when run. The solution for this problem is to provide cc with a way to recognize a position-dependent argument meant for the ld command line. This has been accomplished with a new cc switch: -input_to_ld filename The cc driver interprets this switch as a -input switch destined for ld, and places it on the ld command line in the same relative position that it had on the cc command line. We can now write the above example like this: cc test.o -input_to_ld ldinput ld -g0 -O1 -call_shared /usr/lib/cmplrs/cc/crt0.o test.o -input ldinput -lc Notice that the -input switch has retained its cc command line position. PROBLEM: (QAR 57515) (Patch ID: OSF425-342) ******** There is a problem in cc that causes it to set the incorrect optimization level when the user specifies the "-O -migrate" options. If you compile with the options "-O -migrate -v", you will see that gemc_cc is invoked with -O2 instead of -O4. PROBLEM: (JNC1001) (Patch ID: OSF425-434) ******** This patch adds support for the "-B symbolic" option in the run-time loader. This option to ld(1) alters the search algorithm used in symbol searches. By linking an individual shared libary with the "-B symbolic" option, users gain the flexibility to overide the global search policy for local references within an individual shared library. Instead of starting with the executable file using a breadth-first search order (the default), the loader starts with a shared object using a depth- first search order. If a symbol cannot be resolved in the shared object and its dependencies (if any), the loader then searches the executable file and the other shared objects as it would by default. (Note: The depth-first search avoids symbol preemption confusion that would occur in some cases of a breadth-first search.) PROBLEM: (Patch ID: OSF425-439) ******** This patch provides latent support for DCPI, a performance analysis tool. /sbin/loader will provide information on loaded shared images through a connectionless UNIX datagram socket to DCPI, if DCPI is installed on the system. PROBLEM: () (Patch ID: OSF425-574) ******** This patch provides the support needed by the Developers' Toolkit Update Kit. Installing this patch is required before a Developers' Toolkit Update kit can be installed on a V4.0E system. The patch adds enablers to commands for which newer versions are available in Developers' Toolkit Update releases. The Update versions will be installed as independent binary files. If a patched command finds its Update file to have been installed, it will execute the Update file in place of itself. However, if the "-nodtk" option or a kernel-compiling option is specified, the patched command will continue running, to provide the original functionality. PROBLEM: (QAR 72957) (Patch ID: OSF425-724) ******** 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 .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: (Patch ID: OSF425-042) ******** This patch fixes segfaults in nm for object files generated by the C++ compiler. This problem will only occur for most C++ objects compiled with full debug info using the compiler option "-g", "-g2" or "-g3". nm may produce partial output before the segfault occurs and nm dumps core. PROBLEM: (QAR 69990) (Patch ID: OSF425-696) ******** This patch fixes the name demangling for the tools that print symbol table names generated by the C++ v6.2 compiler. This problem will only occur for most C++ objects compiled with the ansi options. A program compiled with the new C++ compiler with the new ansi name demangling would generate a new demangled function, template, class, etc. Then using one of the dumping tools that lacks the ability to decode (demangle) this string, the output would be unreadable. #include template class C { public: void foo(); }; template class D { public: void foo(); }; main() { C<'b'> c; c.foo(); D<98> d; d.foo(); } with old stdump: Externals table: 0. (file 0) ( 0) main Proc Text symref (indexNil) 1. (file 0) ( 0) foo__19C__tm__10_XCcL_2_98Xv_v Proc Undefined indexNil 2. (file 0) ( 0) foo__19D__tm__10_XCiL_2_98Xv_v Proc Undefined indexNil 3. (file 0) ( 0) _fpdata Global Undefined indexNil with new stdump: Externals table: 0. (file 0) ( 0) main Proc Text symref (indexNil) 1. (file 0) ( 0) void C<'b'>::foo(void) Proc Undefined indexNil 2. (file 0) ( 0) void D<98>::foo(void) Proc Undefined indexNil 3. (file 0) ( 0) _fpdata Global Undefined indexNil PROBLEM: (QAR 73776) (Patch ID: OSF425-785) ******** o 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. o The use of the line continuation character (backslash) gets ignored and the continued line is interpreted as another argument to the linker. PROBLEM: (76358, 76821) (PATCH ID: OSF425-936) ******** 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: (82808) (PATCH ID: OSF425-1064) ******** 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. PROBLEM: (78237) (PATCH ID: OSF425-1072) ******** 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: (77290, 78669, 82501) (PATCH ID: OSF425-1059) ******** 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.