280 lines
		
	
	
	
		
			14 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			280 lines
		
	
	
	
		
			14 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| .\"	List of all warnings; source of warn_msg and warn.h
 | |
| .\"
 | |
| .\"	$Id$
 | |
| .\"
 | |
| .\"	This file contains the warnings issued by the interpreter, together
 | |
| .\"	with their names and values in the code of the interpreter. Some of
 | |
| .\"	the source files of the interpreter are generated from the Wn
 | |
| .\"	macros in this file.
 | |
| .\"	When modifying this file, preserve the parameters of the Wn macros.
 | |
| .de Wn	\" <text> <define> <value>
 | |
| .IP \\$3. 7
 | |
| .B "\\$1"
 | |
| .br
 | |
| ..  Wn
 | |
| .bp
 | |
| .DS C
 | |
| APPENDIX A
 | |
| .DE
 | |
| .SH
 | |
| List of Warnings.
 | |
| .PP
 | |
| The shadow-byte administration makes it possible to check for a
 | |
| wide range of errors during run-time.
 | |
| We have tried to make the diagnostics self-explanatory and especially useful
 | |
| for the C-programmer.
 | |
| The warnings are printed in the message file, together with source file
 | |
| and line number.
 | |
| The complete list of warnings is presented here, followed by an
 | |
| explanation of what might be wrong.
 | |
| Often, these explanations implicitly assume that the program
 | |
| being interpreted, was originally written in C (and not Pascal, Basic etc.).
 | |
| .LP
 | |
| .I "Reading the load file"
 | |
| .Wn "Floating point instructions flag in header ignored" WFLUSED 1
 | |
| .Wn "No float initialisation in this version" WFLINIT 2
 | |
| The interpreter was compiled with the NOFLOAT option; code involving
 | |
| floating point operations can be run as long as the actual
 | |
| instructions are avoided.
 | |
| .Wn "Extra-test flag in header ignored" WEXTRIGN 4
 | |
| The interpreter already tests anything conceivable.
 | |
| .Wn "Maximum line number in header was 0" WNLINEZR 5
 | |
| This number could be used to allocate tables for tallying; these tables are,
 | |
| however, expanded as needed, so the number is immaterial.
 | |
| .Wn "Bad float initialisation" WBADFLOAT 7
 | |
| The loadfile contains a floating point denotation which does not
 | |
| satisfy the syntax (see 2.6).
 | |
| Examining the loadfile (with \fBod \-c\fP) might show the syntax error.
 | |
| Probably there is a bug in the front-end, creating floats with
 | |
| a bad syntax.
 | |
| .LP
 | |
| .I "System calls"
 | |
| .Wn "IOCTL \- bad or unimplemented request" WBADIOCTL 11
 | |
| The second parameter to the ioctl() request (the operation code) is invalid or
 | |
| not implemented; since there are many different opcodes on the various UNIX
 | |
| systems, it is difficult to tell which.  The system call fails.
 | |
| .Wn "MPXCALL \- not (yet) implemented" WMPXIMP 14
 | |
| .Wn "PROFIL \- not (yet) implemented" WPROFILIMP 15
 | |
| .Wn "PTRACE \- not (yet) implemented" WPTRACEIMP 16
 | |
| The monitor calls \fImpxcall()\fP, \fIprofil()\fP and \fIptrace()\fP
 | |
| have not been implemented.  The monitor call fails.
 | |
| .Wn "Inaccessible memory in system call" WMONFLT 21
 | |
| Bad pointers passed to system calls do not cause a memory fault (which in UNIX
 | |
| would happen to the kernel), but cause the system call to fail with the UNIX
 | |
| variable errno set to 14 (EFAULT).  It seems likely that the program is at
 | |
| fault, but there is also a good possibility that a library routine made
 | |
| unwarranted assumptions about word size and pointer size.
 | |
| .Wn "READ \- buffer resides in unallocated memory" WRUMEM 23
 | |
| .Wn "READ \- buffer across global data area and heap" WRGDAH 24
 | |
| When the buffer passed to the read() system call is situated (completely
 | |
| or partially) in unallocated memory (beyond \fIHP\fP) or begins
 | |
| in the global data area and ends in the heap, the appropriate warning
 | |
| is given.
 | |
| The buffer is not written.
 | |
| .Wn "WRITE \- buffer resides in unallocated memory" WWUMEM 25
 | |
| .Wn "WRITE \- buffer across global data area and heap" WWGDAH 26
 | |
| .Wn "WRITE \- (part of) global buffer is undefined" WWGUNDEF 27
 | |
| .Wn "WRITE \- (part of) local buffer is undefined" WWLUNDEF 28
 | |
| The first two are equivalent to the READ-errors above.
 | |
| Writing out a buffer usually makes no sense when the contents are undefined,
 | |
| so one of the latter two warnings will be generated in this case.
 | |
| A global buffer resides in the data partition; a local buffer resides in
 | |
| the stack partition.
 | |
| This corresponds to global and local variables in a C-program.
 | |
| In the first two cases the WRITE is not performed, in the latter two cases
 | |
| it is.
 | |
| .LP
 | |
| .I "Traps and signals"
 | |
| .Wn "SIGTRP \- bad signo argument" WILLSN 31
 | |
| The \fIsigtrp()\fP monitor call allows \fIsig_no\fP arguments in the
 | |
| range [1..17] (UNIX Version 7 signals); the actual argument is out of range.
 | |
| .Wn "SIGTRP \- signo argument is a synchronous trap" WUNIXTR 32
 | |
| The signal is one that can only be caused synchronously by the running program
 | |
| on UNIX; it cannot occur to an interpreted program.
 | |
| .Wn "SIGTRP \- bad trapno argument" WILLTN 33
 | |
| The \fIsigtrp()\fP monitor call allows \fItrap_no\fP arguments between 0 and
 | |
| 252, and the special values \-2 and \-3; the actual argument is not one of
 | |
| these.
 | |
| .Wn "Heap overflow due to command line limitation" WEHEAP 36
 | |
| .Wn "Stack overflow due to command line limitation" WESTACK 37
 | |
| The maximum sizes of the heap and the stack can be limited by options on the
 | |
| command line.  If overflow occurs due to such limitations, the corresponding
 | |
| trap is taken, preceded by one of the above warnings.  If the memory of the
 | |
| interpreter itself is exhausted, a fatal error follows.
 | |
| .LP
 | |
| .I "Run-time type checking"
 | |
| .Wn "Local character expected" WLCEXP 41
 | |
| .Wn "Global character expected" WGCEXP 42
 | |
| .Wn "Local integer expected" WLIEXP 43
 | |
| .Wn "Global integer expected" WGIEXP 44
 | |
| .Wn "Local float expected" WLFEXP 45
 | |
| .Wn "Global float expected" WGFEXP 46
 | |
| .Wn "Local data pointer expected" WLDPEXP 47
 | |
| .Wn "Global data pointer expected" WGDPEXP 48
 | |
| .Wn "Local instruction pointer expected" WLIPEXP 49
 | |
| .Wn "Global instruction pointer expected" WGIPEXP 50
 | |
| In general, a type violation has taken place when one of
 | |
| these warnings is given.
 | |
| The \fBfloat\fP- and \fBinstruction pointer\fP warnings are rare and will
 | |
| usually be easy traceable.
 | |
| \fBInteger/character expected\fP will normally occur when unsigned arithmetic
 | |
| is performed on datapointers or when memory containing objects other than
 | |
| integers is copied bytewise.
 | |
| Often, this warning is followed by a warning \fBdatapointer expected\fP.
 | |
| This is due to our decision of transforming pointers to (unsigned) integers
 | |
| after doing unsigned arithmetic on them.
 | |
| When such a transformed integer is dereferenced (as if it were a pointer)
 | |
| or, in general, when it is treated as a pointer, this results in a warning.
 | |
| The present library implementation of malloc() causes such a
 | |
| sequence of errors.
 | |
| .LP
 | |
| These messages are always followed by a tentative description of what is found
 | |
| in memory at the offending place.
 | |
| .Wn "Actual memory is undefined" WWASUND 61
 | |
| .Wn "Actual memory contains an integer" WWASINT 62
 | |
| .Wn "Actual memory contains a float" WWASFLOAT 63
 | |
| .Wn "Actual memory contains a data pointer" WWASDATAP 64
 | |
| .Wn "Actual memory contains an instruction pointer" WWASINSP 65
 | |
| .Wn "Actual memory contains mixed information" WWASMISC 66
 | |
| If the contents of the area was undefined,
 | |
| check the source code for an uninitialized variable of the mentioned type.
 | |
| Officially, the use of an undefined value
 | |
| should result in a EIUND or EFUND trap but the occurrence is
 | |
| so common that a warning is more appropriate.
 | |
| The contents of memory are described as mixed if the data consists of pieces
 | |
| of different types.  This happens, e.g., when caller and callee do not agree on
 | |
| the types and lengths of the parameters.
 | |
| .LP
 | |
| .I "Protection"
 | |
| .br
 | |
| .Wn "Destroying contents of ROM (at or near loc 0)" WDESROM 71
 | |
| The program stores a value in Read-Only Memory; the only ROM in the present
 | |
| implementation is the area near location 0.  The warning probably results from
 | |
| storing under a NULL pointer.  This is only a warning, the store operation is
 | |
| executed normally.  Reads from location 0 are not detected.
 | |
| .Wn "Destroying contents of Return Status Block" WDESRSB 72
 | |
| The Return Status Block is the stack area containing the return address, the
 | |
| dynamic link, etc.
 | |
| This may or may not be an error.
 | |
| The current implementation of \fIsetjmp()\fP/\fIlongjmp()\fP
 | |
| may be responsible for it.
 | |
| If the program does not use setjmp(), there \fIis\fP something
 | |
| very wrong (e.g. argument for ASP too large).
 | |
| Note that there are some library routines (such as \fIalarm()\fP) which
 | |
| use \fIsetjmp()\fP.
 | |
| .Wn "Logical operation using undefined operand(s)" WUNLOG 81
 | |
| .Wn "Comparing undefined operand(s)" WUNCMP 82
 | |
| The logical operations AND, XOR, IOR, COM and the compare operation
 | |
| CMS do their jobs bytewise.
 | |
| If one of the bytes is found to be undefined, the corresponding warning
 | |
| is given, and the operation is stopped immediately.
 | |
| The stack is adjusted so interpretation may continue.
 | |
| .br
 | |
| It is hard to say what went wrong.
 | |
| Possibly, the argument of the instruction at hand (which indicates the
 | |
| size of the objects to be compared), was too large.
 | |
| .LP
 | |
| .I "Bad operands"
 | |
| .Wn "Shift over negative distance" WSHNEG 91
 | |
| .Wn "Shift over too large distance" WSHLARGE 92
 | |
| Shift instructions yield undefined results if the shift distance is negative
 | |
| or larger than the object size.
 | |
| .Wn "Pointer arithmetic yields pointer to bad segment" WSEGADP 93
 | |
| When doing pointer arithmetic (ADP, ADS), the operand and result pointer
 | |
| must be in the same \fIsegment\fP (see sec. 4).
 | |
| E.g. loading the address of the first local and adding 20 to it will
 | |
| certainly give this warning.
 | |
| .Wn "Subtracting pointers to different segments" WSEGSBS 94
 | |
| Pointers may be subtracted only if they point into the same segment.
 | |
| .Wn "Pointer arithmetic with NULL pointer" WNULLPA 96
 | |
| By definition it is illegal to do arithmetic with null pointers.
 | |
| Integers with the size of a pointer and the value zero are recognized
 | |
| as NULL pointers.
 | |
| A well-known C-trick to compute the offset of some field in a struct
 | |
| is converting the null-pointer to the type of the struct and simply
 | |
| taking the address of the field.
 | |
| This trick will \-when translated and interpreted\- generate this warning
 | |
| because it results in arithmetic with the NULL pointer.
 | |
| .LP
 | |
| .I "Return area"
 | |
| .Wn "Returned function result too large" WRFUNLAR 101
 | |
| .Wn "Returned function result too small" WRFUNSML 102
 | |
| This warning is generated when the size of the expected return value
 | |
| is not equal to the size actually returned.
 | |
| .br
 | |
| An interpreted program may have fallen through the end of
 | |
| the code without explicitly doing an \fIexit()\fP or \fIreturn()\fP.
 | |
| The start-up routine (\fIcrt0()\fP) however always expects to get some
 | |
| value returned by the program proper.
 | |
| .br
 | |
| Another (less probable) possibility of course is that the code contains
 | |
| a subroutine or function call that does not return properly (e.g.
 | |
| it returns a short instead of a long).
 | |
| .Wn "Returned function result may be garbled" WRFUNGAR 103
 | |
| This warning will be generated, when the contents of the FRA are fetched
 | |
| after some instruction is executed which can mess up the area.
 | |
| Compiler-generated loadfiles should not generate this message.
 | |
| .LP
 | |
| .I "Return Status Block"
 | |
| .Wn "RET did not find a Return Status Block" WRETBAD 111
 | |
| .Wn "Used RET to return from a trap" WRETTRAP 112
 | |
| The RET instruction found a garbled Return Status Block, or on that resulted
 | |
| from a trap.
 | |
| .Wn "RTT did not find a Return Status Block" WRTTBAD 115
 | |
| .Wn "RTT on empty stack" WRTTEMPTY 116
 | |
| .Wn "Used RTT to return from a call" WRTTCALL 117
 | |
| .Wn "Used RTT to return from a non-returnable trap" WRTTNRTT 118
 | |
| The RTT (Return from Trap) instruction found a Return Status block that was not
 | |
| created properly by a trap.
 | |
| .Wn "Stack Pointer too large in RET" WRETSTL 121
 | |
| .Wn "Stack Pointer too small in RET" WRETSTS 122
 | |
| .Wn "Stack Pointer too large in RTT" WRTTSTL 125
 | |
| .Wn "Stack Pointer too small in RTT" WRTTSTS 126
 | |
| According to the EM Manual (4.2), "the value of SP just after the return
 | |
| value has been popped must be the same as the
 | |
| value of SP just before executing the first instruction of the
 | |
| invocation."
 | |
| If the Stack Pointer is too large, some dynamically allocated item or some
 | |
| temporary result may have been left behind on the stack.
 | |
| If the Stack Pointer is too small, some locals have been unstacked.
 | |
| Since the interpreter has enough information in the Return Status Block, it
 | |
| recovers correctly from these errors.
 | |
| .LP
 | |
| .I "Traps"
 | |
| .LP
 | |
| Some traps have ambiguous or non-obvious causes.
 | |
| As far as possible, these are preceded by a warning, explaining the
 | |
| circumstances of the trap.
 | |
| .Wn "Trap ESTACK: DCH on bad LB" WDCHBADLB 131
 | |
| .Wn "Trap ESTACK: LPB on bad LB" WLPBBADLB 132
 | |
| .Wn "Trap ESTACK: SP retracted over Return Status Block" WSPGTLB 133
 | |
| .Wn "Trap ESTACK: SP moved into data area" WSPINHEAP 134
 | |
| .Wn "Trap ESTACK: SP set to non-word-boundary" WSPODD 135
 | |
| .Wn "Trap ESTACK: LB set out of stack" WLBOUT 136
 | |
| .Wn "Trap ESTACK: LB set to non-word-boundary" WLBODD 137
 | |
| .Wn "Trap ESTACK: LB set to position where there is no RSB" WLBRSB 138
 | |
| .Wn "Trap EHEAP: HP retracted into Global Data Area" WHPGDA 141
 | |
| .Wn "Trap EHEAP: HP pushed into stack" WHPSTACK 142
 | |
| .Wn "Trap EHEAP: HP set to non-word-boundary" WHPODD 143
 | |
| .Wn "Trap EILLINS: unknown opcode" WBADOPC 151
 | |
| .Wn "Trap EILLINS: conversion with unacceptable size for this machine" WILLCONV 152
 | |
| .Wn "Trap EILLINS: FIL with non-existing address" WILLFIL 153
 | |
| .Wn "Trap EILLINS: LFR with too large size" WILLLFR 154
 | |
| .Wn "Trap EILLINS: RET with too large size" WILLRET 155
 | |
| .Wn "Trap EILLINS: instruction argument of class c does not fit a word" WARGC 156
 | |
| .Wn "Trap EILLINS: instruction on double word on machine with word size 4" WARGD 157
 | |
| .Wn "Trap EILLINS: local offset too large" WARGL 158
 | |
| .Wn "Trap EILLINS: instruction argument of class g not in GDA" WARGG 159
 | |
| .Wn "Trap EILLINS: fragment offset too large" WARGF 160
 | |
| .Wn "Trap EILLINS: counter in lexical instruction out of range" WARGN 161
 | |
| .Wn "Trap EILLINS: non-existent procedure identifier" WARGP 162
 | |
| .Wn "Trap EILLINS: illegal register number" WARGR 163
 | |
| .Wn "Trap EBADPC: jump out of text segment" WPCOVFL 172
 | |
| .Wn "Trap EBADPC: jump out of procedure fragment" WPCPROC 173
 | |
| .Wn "Trap EBADGTO: GTO does not restore an existing RSB" WGTORSB 181
 | |
| .Wn "Trap EBADGTO: GTO descriptor on the stack" WGTOSTACK 182
 | |
| .Wn "Trap caused by TRP instruction" WTRP 191
 | |
| .ig
 | |
| .Wn "Last warning" WMSG 199
 | |
| !Leave these lines here!
 | |
| ..
 |