dupuy@cs.cs.columbia.edu (Alexander Dupuy) (02/08/89)
In article <4180@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: > > /bin/sh allocates 2meg to overcome a problem with restarting instructions > on a 68030 (/bin/sh used to handle SIGSEGV's to extend its break region, > that doesn't work on a 68030). Am I reading this right? I remember that there was a problem with the 68000 (the original) being unable to restart some instructions - that was why you needed a 68010, which allowed you to restart all instructions, if you wanted to have a demand-paged virtual memory system. Is it really true that the 68030 has the same proble the 68000 had? Doesn't sound like progress to me... Please respond by mail - I don't read these groups very regularly. @alex -- -- inet: dupuy@cs.columbia.edu uucp: ...!rutgers!cs.columbia.edu!dupuy
friedl@vsi.COM (Stephen J. Friedl) (02/08/89)
In article <4180@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: < < /bin/sh allocates 2meg to overcome a problem with restarting instructions < on a 68030 (/bin/sh used to handle SIGSEGV's to extend its break region, < that doesn't work on a 68030). In article <DUPUY.89Feb7144542@cs.cs.columbia.edu>, dupuy@cs.cs.columbia.edu (Alexander Dupuy) writes: < < Am I reading this right? I remember that there was a problem with the 68000 < (the original) being unable to restart some instructions - that was why you < needed a 68010, which allowed you to restart all instructions, if you < wanted to have a demand-paged virtual memory system. Is it really true < that the 68030 has the same proble the 68000 had? How about looking at this from the other direction. Why in world does the shell *still* use SIGSEGV this way? Does the SVR3 shell still do this? An incredulous Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for you only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl Nancy Reagan on these *stupid* .signatures: "Enough already, OK?"
rob@tolerant.UUCP (Rob Kleinschmidt) (02/11/89)
In article <28200272@mcdurb>, aglew@mcdurb.Urbana.Gould.COM writes: > > >How about looking at this from the other direction. Why in world > >does the shell *still* use SIGSEGV this way? Does the SVR3 shell > >still do this? > > > >Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com > > But - why shouldn't the shell expect to be able to implicitly allocate > memory? > > IE. its use of SIGSEGV is equivalent to malloc'ing all 2GB of virtual address > space (modulo the limitations of your hardware), but not having swap space, > > Anyway, to sum up: systems should provide a way for low-overhead virtual > address space - basically, to fault-allocate (as opposed to the more common > faulting in of already allocated) memory. I suspect that not doing so is > an artifact of hardware distinctions between allocated and unallocated > virtual memory. > > And to avoid flames: yes, of course you do not always want to fault in address > space. I've found bugs with SIGSEGV too. Explicit allocation is a good > discipline. But not always. > > > Andy "Krazy" Glew aglew@urbana.mcd.mot.com uunet!uiucdcs!mcdurb!aglew > Motorola Microcomputer Division, Champaign-Urbana Design Center > 1101 E. University, Urbana, Illinois 61801, USA. > The attempt by shell to catch SIGSEGV signals and allocate memory can create major problems on architectures where faults do not occur on instruction boundaries (68000 series for example). On the Motorola line, the fault basically occurs mid-instruction, and it is possible to continue from this point, but any change to the pc can produce bizarre results because of pipeline information contained within the bus error exception frame on the supervisor stack. Note that normal memory allocation will work fine because there is no alteration of the pc. To handle a signal under circumstances of this kind, the system must either (a) run to an instruction boundary, (b) save and later restore the processor state, or (c) discard the bus error frame, leaving the program unable to continue out of the fault condition. (there may be other solutions here, but these seem to be the most common). Running to an instruction boundary would be interesting, but could require temporary allocations of memory which the program had not requested, and which might later have to be discarded. I do not know of anyone who has attempted this solution. Saving and later restoring a bus error frame has problems because of potential recursion. If saved in kernel space, there is limited storage available. If saved in user space, this potentially leaves the processor state open to user modification (not nice at all !!). Trashing the faulted access leaves the shell unrunable (early versions at least). Admittedly, faulting mid instruction is not a nice thing to do, but then neither are unix signals. Not sure what problems exist on other processor lines, or what other solutions have been implemented here. In my own experience, I have never seen anything 100% satisfactory. (first attempt at a reply here, please bear with me) R. Kleinschmidt