PROBLEM: (81960) (PATCH ID: OSF510-022)
********
When trying to spike a kernel, for instance with a line such as this:
spike -kernel vmunix.orig -o vmunix.tmphaha

the following error message is given:

? FATAL ERROR
? Assertion failed.
? ../../../../../../src/usr/ccs/bin/spike/rawrel.unix.cxx, line 2755
NO STACKTRACE  no executable specified
Floating exception (core dumped)


PROBLEM: (78237) (PATCH ID: OSF510-153)
********
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 <null>

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.


PROBLEM: (83306) (PATCH ID: OSF510-108)
********
Using the -A switch with the linker (ld) produces link errors such as:
ld:
Object file format error in: main: Unrecognized tag (0xf) in .comment section.


PROBLEM: (82808) (PATCH ID: OSF510-120)
********
  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: (77290, 78669, |) (PATCH ID: OSF510-102)
********
|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: (87682) (PATCH ID: OSF510-258)
********
  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: (86688) (PATCH ID: OSF510-240)
********
  This patch fixes a linker failure that can occur when performing a 
  -non_shared link with both libexc.a and an input object that requires 
  section alignment.
  Prior to this patch, the linker would fail to link the following
  program, as shown below:

   %cat bug1.c
    #include <excpt.h>
    __align(5) long sdata_align_var = 0xdeadbeef;

    main() {
       try {
          printf("a");
       } except(printf("b"), 5) {}
    }

    % cc bug1.c -lexc -non_shared
    ld:
    build_scnhdr: DATA scnptr bad; Last section was .data
      New section .xdata should go at 0x4adb0 but scnptr is at 0x4adc0


PROBLEM: (89858) (PATCH ID: OSF510-399)
********
 When "-update_registry <registry_file>" is specified on the same
 shared object registry file by concurrent linker processes, each
 process writes the registry_file.  Concurrent writes to the registry 
 file may leave it in a corrupted state.
 With this patch, the linker now locks the registry file, which ensures 
 that only one link process at a time can modify the file, thus preventing 
 the corruption.

 With this patch, the linker now locks the registry file when -lock_registry
 is specified.  This ensures that only one link process at a time can modify
 the file, thus preventing the corruption.  The -lock_registry flag is a new
 linker flag with this patch.