PROBLEM:      (Patch ID: OSF435-055)
********
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.

This patch also addresses QAR64978, ensuring that the above-mentioned support 
for DCPI does not break setlocale support.

PROBLEM:  (JNC1001)    (Patch ID: OSF435-062)
********
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 library with the "-B symbolic" option,
users gain the flexibility to override 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 its symbol resolution search at the
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:  (none)    (Patch ID: OSF435-141)
********
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: OSF435-276)
********
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 69990)    (Patch ID: OSF435-207)
********

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++ with the new ansi name demangling
would generate a new demangled function, template, class, ... then
using one of the dumping tools with out the correct way to decode
(demangle) this string the output would be unreadable.


#include <String.hxx>

template <char c>
class C { 
public:
        void foo();
};
template <int d>
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: OSF435-339)
********
When using the -input <filename> 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: OSF435-339)
********
The use of the line continuation character (backslash) gets ignored
and the continued line is interpreted as another argument to the
linker.