dave@smaug.UUCP (Dave Cornutt) (06/10/86)
Keywords: signal UN*X boundary stack Summary: more about the signal mechanism and error reporting Line eater: yes I seem to have stirred up quite a bit of activity with my original posting about signals and error reporting. Well, at least now I know that our feed site is working. Chris Torek and others have posted their suggestions for all-purpose error reporting routines, and I intend to implement one of these on our machine; it sure make my life easier! (As well as reduce the temptation to put in those "can't open file"-type messages.) Thanks for your ideas. About signals: Someone (sorry, I lost the article and I can't remember who it was) correctly pointed out to me that the "abort" system call generates an IOT signal. You're right, I had forgotten about that beastie. I got some replies detailing the history of the siganl system, including one which listed the (quite amusing) original names for the signals. (Reminds me of the bad old days under V6 and its one-letter shell variable names.) I also received some flames accusing me of trying to adopt the signal system to a Gould architechure, such as the following (polyof.203): >Seems to me that you are guilty of the same "crimes" you accuse the "pdp11" >folks of. Several of your so-called "machine-independent" traps, like >Stack overflow, Boundary condition are slanted toward the (clumsy) Gould-like >architechure. Many machines know how to handle stack violations correctly (by >growing the stack; in fact to not grow the stack automatically is probably a >flaw with the implementation or architecture.) >Imagine getting a stack overflow on a pdp11? what does that mean? (in a user >program that is) Is it the same as a segmentation violation? (stack collides >with data?) or what? Very unclear. >Boundary violations (doubleword, whatever) also fall into this category. >Some machines allow 'odd' addresses for words (Intel, for example), others >do not. Hence, Boundary condition is not machine independent. > >The bottom line is, it is very difficult to isolate the individual >flaws/features of every architecture and have accurate error reporting >under a single OS (that is portable). >It is not impossible, but difficult. Software compatibility must be >maintained as well. If the signal structure is changed for each machine, >this becomes difficult. > >John Buck >Polytechnic Inst. of NY >Route 110 >Farmingdale, NY 11735 >trixie!polyof!john >iguana!polyof!john I did NOT advocate a different signal structure for each machine. If you will go and reread my original posting, you will see that one of the things that I wanted was a range of signals reserved for machine-specific traps and defineable by each implementor. Boundary conditions are not unique to Gould machines; the 68000, for example, also has boundary restrictions and odd- address traps (and so does the pdp-11, of course). So, although the specific boundary conditions are Gould-specific, the boundary trap itself is not. The idea is that the boundary trap should be a standard UN*X signal. On machines such as the VAX, which do not have boundary restrictions, this signal would simply never occur. I should point out that the various compilers isolate the programmer from having to worry about boundary restrictions; I have never had a boundary program with anything that I wrote on this system (and a lot of this has been ported to other machines). The only place where you can get in trouble is if you play funny games with pointers (like casting a char * into an int *), and the only place where I have actually seen that happen was in a simulation program that we purchased which was written originally on the VAX, which insisted on building structures in memory through pointer manipulation rather then using structure types. If you take reason- able care to write in a portable manner, you should have no trouble going from a VAX to a PN6000/9000 or vice versa. As for the stack overflow condition, I will admit that it is better to grow the stack automatically. However, even if our architechure was capable of doing this, I would still retain the stack overflow signal. Further, I claim that if standard BSD doesn't have this signal, it should. Why? Suppose you have a program that gets into a loop calling a routine recursively. Do you want your stack to keep growing until it uses up all of the swap space on your machine? Even virtual memory isn't infinite. Even if you have some sort of memory quota to keep this from happening, what happens if stack expansion causes the quota to be exceeded? (A question for all you BSD gurus: what does happen in this situation?) The stack overflow does NOT have anything to do with data space (except that they may be sharing the same memory). The difference between running out of data space and running out of stack space is that the former can only occur as the result of a brk() or sbrk() system call (either directly or indirectly as a result of calling malloc), while running out of stack can occur AT ANY TIME. What I don't want is to have this mapped to, say "segmentation violation", just for the sake of having it fit into an existing signal; this is clumsy if you are going to catch the signal, and it's worse than worthless as a debugging aid, since it gives you an incorrect indication of what the problem is. As for the truly machine-dependent signals, their usage would be implementor- defined and of course nonportable. You might be able to do some fancy stuff by catching machine-dependent signals. (For example, our machine has a "console attention" trap that can be issued from the system console that I could probably find some nifty use for if there was a way to handle it.) The PDP-11 interrupt-type instructions (IOT, EMT, etc.) would fit in to this range. Note also that one of the other things that I asked for is a range of user-defined signals guaranteed NOT to be issued by the kernel; this would eliminate having to use unused or undefined signals for software purposes. Dave Cornutt Gould Computer Systems Ft. Lauderdale, FL "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."