Google
 

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