123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280 |
- .\" 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!
- ..
|