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 <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)
********
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