Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site wlcrjs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!wlcrjs!rhesmith From: rhesmith@wlcrjs.UUCP (Richard H. E. Smith II) Newsgroups: net.unix-wizards Subject: Re: stack space mapping question Message-ID: <551@wlcrjs.UUCP> Date: Fri, 8-Feb-85 08:04:32 EST Article-I.D.: wlcrjs.551 Posted: Fri Feb 8 08:04:32 1985 Date-Received: Sat, 9-Feb-85 06:26:33 EST References: <21131@arizona.UUCP> <248@cheviot.UUCP> Reply-To: rhesmith@wlcrjs.UUCP (Richard H. E. Smith II) Distribution: net Organization: chi-net, Public Access UN*X, Chicago IL Lines: 59 Summary: Strange historical sidenote This is a little bit of obscure history of interest to pdp-11 users, and slightly aged unix hackers. You can skip out now if this isn't your sort of thing. Otherwise, please bear with the long quotes: >>In article <21131@arizona.UUCP> whm@arizona.UUCP (Bill Mitchell) asks: >>whether stack pages grabbed while the stack is deep are ever reclaimed >>by the system when the stack recedes. >> >> On 4.2 on Suns and Vaxes, the system does allow (based >>on empirical studies rather than code examination) access to pages below >>the sp as long as they were properly contained in the stack at some point >>in time. Is this implementation dependent or is this some sort of standard >>Unix "feature"? >In article <248@cheviot.UUCP> robert@cheviot.UUCP (Robert Stroud) writes: >I don't know about more recent versions of Unix, but this was a "feature" >of the PDP-11 V7 implementation where I first met Unix. I used it to extend >my data area beyond 56K without fear of a segmentation violation. > >The memory mapping hardware on this PDP-11 restricted you to 8 segments, each >of which could address up to 8K in steps of 64 bytes - or something like that. >Because Unix must always have a stack segment, you couldn't extend your memory >(using sbrk) beyond 56K (or 8 - 1 segments). > >However, if you extended the stack segment to its full 8K by setting, >de-referencing and then re-setting the stack pointer, and set your break >to 56K, then the full 64K address space was addressable without any >danger of segmentation violation, and you could sneak a few extra bytes... > >I wasn't particularly proud of this trick, but it got me out of a hole. >If anyone else out there is still using PDP-11's(!), they may find it useful. If the pdp-11 wasn't being used in its "separate instruction and data space" mode, you could do something even stranger... you could hang it up completely. I did this to UNIX[tm] V6 back at the University of Wisconsin, in '74 or '75. The pdp-11/45 has a privileged instruction SPL, which was a NOP in user state except that it would hold interupts for one instruction (oops! a microcode bug!). By carefully allocating data and stack, one could fill the entire 32Kword address space with SPL instructions, and lock up the cpu completely. All of address space except one NOP would really annoy the other users, but did (eventually) allow interrupts. Either looked nice in the lights, too. I don't believe that the 11/70 cpu or later cpus have this microcode bug. I don't advise you to test it... you must reset from the front panel after the crash... altho a really skilled sysadm can spot this loop, and patch it out of existance from the switches... somehow, I imagine that anyone still running an 11 has such. (No, I'm not picking on you. I write 11 software for a living.) To do the trick, I believe that some strange balance of allocating stack and brk() memory had to be used, because the kernel allocated stack to the program in some multiple of 3(?) 32word hunks. Now, who remembers the one-instruction core clear? -- ---------- Dick Smith ..ihnp4!wlcrjs!rhesmith