Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
lnkv51.d07
There is 1 other file named lnkv51.d07 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR LINK-10-V5-1
EDIT 1542 FOR LINK
[SYMPTOM]
LINK dies or writes into the wrong section when writing large
extended addressing program.
[DIAGNOSIS]
At certain places in the core manager the section number is added
to an address that already contains the section number.
[CURE]
Don't add the section number.
********************************************************************************
EDIT 1543 FOR LINK
[SYMPTOM]
LNKMEF when building large programs in non-zero sections.
[DIAGNOSIS]
LINK gets confused when it tries to write the local symbols to an
overflow file. It thinks they are being overflowed into another
section in the fork, and tries to create section zero. This fails.
[CURE]
Don't let the code think it is doing extended addressing when
writing the LS overflow file.
********************************************************************************
EDIT 1544 FOR LINK
[SYMPTOM]
When generating an overlay plot to the line printer LINK gets an
illegal memory reference.
[DIAGNOSIS]
In PLTIO the code uses DIGITS to determine when it has finished
processing a buffer of data. DIGITS is not correctly set to zero
before the calculation.
[CURE]
Replace the SETZ DIGITS with SETZM DIGITS.
********************************************************************************
EDIT 1545 FOR LINK
[SYMPTOM]
LINK does not type the module in some errors where it should.
[DIAGNOSIS]
The continuation bit is not set.
[CURE]
Set the continuation bit.
********************************************************************************
EDIT 1546 FOR LINK
[SYMPTOM]
The USELIB macro does not work properly.
[DIAGNOSIS]
The user library code was changed to use bits for the compiler
type. The MAKLIB macro in LNKINI was not updated.
[CURE]
Change the MAKLIB macro to use bits.
********************************************************************************
EDIT 1547 FOR LINK
[ SYMPTOM ]
An illegal memory read occurs if LINK 5.0 attempts to read a .REL
file having a byte size other than 36. This includes ASCII .REL files
and ordinary .REL files that have been processed by certain unsupported
utilities.
[ DIAGNOSIS ]
Unlike previous versions of LINK, version 5.0 uses the number of bytes
in the file to compute its length, incorrectly assuming that the bytesize
is always 36. If the bytesize is smaller than 36 LINK tries to read
past the end of the file.
[ CURE ]
Check the byte size set in the file's FDB. If it is zero, default to
a byte size of 36 bits. Use this and the byte count to compute the
correct size of the file.
********************************************************************************
EDIT 2031 FOR LINK
[SYMPTOM]
LINK sort of acts like it's loading overlays when loading a FORTRAN
V7 program. It searches SYS:OVRLAY, and it will complain about
/SEGMENT:HIGH with overlayed programs, for example.
[DIAGNOSIS]
FORTRAN V7 emits a writable overlay block. This causes the
"writable overlay" bit to be set in OVERLW. A non-zero OVERLW
indicates to some parts of LINK that overlay action should be
taken.
[CURE]
If OVERLW is zero (no /OVERLAY switch has been seen) don't set the
writable overlay bit in OVERLW.
********************************************************************************
EDIT 2032 FOR LINK
[SYMPTOM]
LINK may write a bad .EXE file for programs with overlays. much of
the root node will be missing.
[DIAGNOSIS]
If the root node is too large to be read back into memory to build
the .EXE file, LINK copies it into an LC overflow file. In doing
so, it gets confused and unmaps pages which it belives are mapped
to the overflow file. Unfortunately, these pages are private, and
therefore gone.
[CURE]
Map the pages to the overflow file before reading the low segment
code into them. Then when they are unmapped, they will be in the
overflow file where they belong.
********************************************************************************
EDIT 2033 FOR LINK
[SYMPTOM]
LINK may lose part of the symbol table of large programs with
overlays. This could cause a defective map, a bad symbol table in
the program, or possibly an LNKSFU or LNKCNW error.
[DIAGNOSIS]
The TOPS-10 style core manager could handle LW.LS being on a
TOPS-10 disk block bound. The TOPS-20 style core manager requires
that the pages be on a TOPS-20 page bound. The code that copies
the local symbols from the LS overflow file into the overlay temp
file attempts to keep one block of symbols around.
[CURE]
On TOPS-20, keep a page of symbols around.
********************************************************************************
EDIT 2034 FOR LINK
[SYMPTOM]
Possible IO to unassigned channel on TOPS-10, performance
degradation when writing a .EXE file on either TOPS-10 or TOPS-20.
[DIAGNOSIS]
The TOPS-20 native code which opens files checks for .IODMP to
determine whether to allocate buffers. However the code which
calls this routine to open the .EXE file sets .IODPR, so buffers
are allocated anyways. The core manager moves areas of memory to
get the space for the buffers, destroying the memory layout
carefully set up for the .EXE file writer. Edit 1531 attempted to
teach the .EXE file writer how to deal with the new memory layout,
but has side effects.
[CURE]
Change the TOPS-20 code to check for .IODPR, and remove edit 1531.
********************************************************************************
EDIT 2035 FOR LINK
[SYMPTOM]
Possible ?Illegal memory write when loading a large program which
is not being written to an EXE file.
[DIAGNOSIS]
In order to remove the low and high segment overflow files, LINK
maps them in copy-on-write, and then touches each page to make it
private. However, if a page does not exist, it cannot be touched
and made private.
[CURE]
Check for nonexistant pages in the overflow file, and do not map
them in.
********************************************************************************
EDIT 2036 FOR LINK
[SYMPTOM]
There are problems with abbreviations for /DEBUG:DDT. Also, there
is no compiler type for ADA.
[DIAGNOSIS]
LINK belives the Jovial debugger is DDT, which causes unique name
problems. No compiler type has been assigned for ADA.
[CURE]
Remove /DEBUG:JOVIAL, which only runs DDT. Add ADA as a compiler.
********************************************************************************
EDIT 2037 FOR LINK
[SYMPTOM]
Under certain circumstances, loading FORTRAN V7 programs can cause
an Illegal memory reference, or a bad fixup.
[DIAGNOSIS]
When defining a global symbol which already has been requested,
LINK checks for any secondary triplets. If it finds some, it
searches them to see if any indicate additive global fixups. With
FORTRAN V7, there can be a secondary triplet for argument
typechecking. The code which searches the secondary triplets stops
when it finds a new primary triplet. If the symbol being defined
happens to be the last primary triplet in the global symbols area,
LINK will walk off the end of the area looking for the next primary
or an additive fixup.
[CURE]
Teach the code to check the bit S.LST, which indicates the last
secondary triplet for a given symbol. This is more reliable than
looking for the next primary.
********************************************************************************
EDIT 2040 FOR LINK
[SYMPTOM]
LINK gets an illegal instruction 0,,0. Observation shows that all
of LINK's high segment is gone, along with much of it's low
segment.
[DIAGNOSIS]
When the local symbols area is paging, LINK unmaps the area at
SYMINI, prior to reading in the last few pages of the symbol table.
An error in the calculations can lead to calling LS.OUT with the
lower bound higher than the upper bound. The TOPS-10 overflow
handler did not care about this, as it built an IOWD which would
not write anything out. The TOPS-20 overflow handler belives that
this specifies a section crossing, and unmaps all pages from the
lower bound through the upper bound in section 1.
[CURE]
Check for this special case, and write out the one page which is
mapped. The lower bound is correct, but the upper bound is one
page below where it should be. Add one page to the upper bound.
********************************************************************************
EDIT 2041 FOR LINK
[SYMPTOM]
If an explicit PPN is given, and the directory is specifies is very
long LINK may clobber it's stack, resulting in many possible
errors.
[DIAGNOSIS]
LINK allocates space from the stack to build an ASCIZ copy of the
filespec from the SCAN block. It is not allocating a large enough
piece.
[CURE]
Increase the size of the block.
********************************************************************************
EDIT 2042 FOR LINK
[SYMPTOM]
LINK generates LNKISN, LNKSNP, or a bad .EXE file when linking a
large overlayed program.
[DIAGNOSIS]
Pointers are not properly saved accross the calls to TR.WLK.
[CURE]
Convert the pointers to offsets before calling TR.WLK, and convert
them back to absolute addresses after the call.
********************************************************************************
EDIT 2043 FOR LINK
[SYMPTOM]
?LNKRUM error at end of loading, before writing .EXE file.
[DIAGNOSIS]
LINK needs memory to build the .EXE file directory and buffer. It
is possible for LINK to start paging the LC area while trying to
get this memory. If this happens, the JOBDAT area is in the LC
area. There is code which belives that if the LC area is paging
that the program's JOBDAT is in in the DY area. This code tries to
move JOBDAT to the LC area, and to give back the DY space. Since
the DY space has not been allocated, and the pointer is zero, the
core manager complains when the memory is returned.
[CURE]
Check for a zero pointer. If the pointer is zero, the JOBDAT is
already in the LC area. Don't try to move it or return space in
the DY area.
********************************************************************************
EDIT 2044 FOR LINK
[SYMPTOM]
%LNKSFU errors, or possibly other errors or channel 22 interrupts.
[DIAGNOSIS]
When LINK creates a new heap (usually the FX area for fixups), it
does so by extending the previous heap by one page and then
trimming that page for the new heap. When the LS area has
overflowed to disk on TOPS-20, the LS page is immediately mapped to
disk when the area is expanded. That page is not unmapped when the
page is given to the FX area. This causes fixups to be written on
that disk page, corrupting the LS overflow file.
[CURE]
There is code to unmap the page, but it does not work properly, and
it is not called in this case anyways. Fix it and make sure it is
called.
********************************************************************************
EDIT 2045 FOR LINK
[SYMPTOM]
Forward polish references to FORTRAN subroutines or functions are
not resolved. Other types of references may also not be resolved.
[DIAGNOSIS]
The argument checking code does not properly handle the case where
a symbol has no argument checking block, but does have other
secondary tripletts.
[CURE]
Fix this case.
********************************************************************************
EDIT 2046 FOR LINK
[SYMPTOM]
?LNKMEF error from LINK when loading very large FORTRAN 77
programs.
[DIAGNOSIS]
FORTRAN 77 generates argument checking information. LINK keeps
this information around until it needs it. In large programs with
thousands of subroutine calls, LINK will need to allocate and
deallocate memory many times, causing fragmentation.
[CURE]
Combine contiguous areas occasionally to prevent excess
fragmentation. This will allow loading larger programs before the
memory runs out.
********************************************************************************
EDIT 2047 FOR LINK
[SYMPTOM]
If a FORTRAN module loaded /SEGMENT:HIGH attempts to initialize
common variables in a common block which has been allocated in the
low segment, LINK will not load the data properly, and may die.
[DIAGNOSIS]
LINK thinks that if a common block is being initialized by a
/SEG:HIGH module, that the common block must be in the high
segment. It stores the data in the wrong place.
[CURE]
Remove the code that makes this incorrect assumption.
********************************************************************************
EDIT 2050 FOR LINK
[SYMPTOM]
The message "?LNKSUP Loading Suppressed" does not appear in column
one. This prevents batch jobs from working properly.
[DIAGNOSIS]
The error message was written with the question mark in the wrong
place.
[CURE]
Put a CRLF in before the question mark.
********************************************************************************
EDIT 2051 FOR LINK
[SYMPTOM]
LINK gets a fatal error and requests the user to submit an SPR if the
first directory in DSK: cannot be written to and a .TMP file is being
created.
[DIAGNOSIS]
The code improperly handles the error. Channel I/O blocks are not
setup before certain routines are called, causing the fatal error.
[CURE]
Remove the incorrect TOPS-20 conditional code. Handle the error the
same way as for TOPS-10, namely, push the offending channel number
onto the stack and use the .ERR. macro to announce the error.
********************************************************************************
EDIT 2052 FOR LINK
[SYMPTOM]
When trying to make an EXE file on a directory that is protected
against the user, LINK gets an illegal instruction trap.
[DIAGNOSIS]
LINK cannot get a JFN on the file due to the protection of the
directory. When LINK tries to print an error message to this effect,
it uses the JFN it thought it had to type the offending filename. In
this case however, there was no JFN so the JFNS% JSYS failed.
[CURE]
Don't try to use a JFN to type the filename. Push the internal
pseudo-channel number onto the stack and do a conventional .ERR. call
to announce the error.
********************************************************************************
END OF LINK-10-V5-1