Subject: Elk internals [was: Re: 32-bit crunching in Scheme?]
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 1998/12/16
Newsgroups: comp.lang.scheme
Message-ID: <757gla$3lbpo@fido.engr.sgi.com>
Andy Gaynor  <silver@mail.webspan.net> wrote:
+---------------
| Rob Warnock wrote:
| > But you only need that if you're going to use the generational collector,
| > which requires that the O/S support "mprotect()".
| 
| Or mmap (right?).  Got it, been in there for a long while, hasn't it?
+---------------

No, the only use of "mmap()" in "heap-gen.c" is as a replacement for the
"malloc()", when building/expanding the heap, and even then only in the
third case below:

  Parameter in		Means				      Can do  
  "system" file						      gen-GC? 

  mprotect=no	 System has no mprotect() call			NO	
  mprotect=yes	 System has mprotect(), usable for any address	Yes	
  mprotect=mmap	 Has mprotect(), but *only* for mmap()'d pages	Yes	

That is, in the third case, the workaround is to only allow mutable
heap objects to live in space allocated by:

	mmap (0, size, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0)

+---------------
| > And from looking at the "i486-linux-gcc" system file [and rummanging around
| > with "man" & "apropos" on a local Linux system] it looks like maybe Linux
| > doesn't support [mprotect()] anyway, so don't worry about it and just use
| > the stop-and-copy collector.
| 
| ..."But I waaaaannnnt iiiiiiiit.".
| I looked in a bunch of other config files...  mprotect=yes ...
| Isuspect that the old config is simply very dated.
+---------------

I think you're right. Turns out that the Linux system I looked on hadn't
had the man pages installed(!!), so no wonder I didn't find "mprotect()"!!
I looked on a different system, and clearly Linux [at least, Red Hat 5.2]
*does* have "mprotect()", and does not restrict it to use on mmap'd segments.
So "mprotect=yes" sholud be fine.

(And even though the "mmap" man page *doesn't* mention it, its "mmap" does
have the "MAP_ANON" bit defined in the header files, so "mprotect=mmap"
should work, too.)

+---------------
| sigsegv_addr=siginfo
| # There is no siginfo_t in Linux's sigaction structure.
| # I have no clue about the usage of sigcontext and meaning of its fields
| #  (gs, __gsh, ..., edi, esi, ebp, esp, ebx, ...)
| #  Many look a heluva lot like x86 register names.
| # arg4 doesn't (appear to) apply.
| # Screwed?
+---------------

Maybe not. First look at /usr/include/asm/sigcontext.h at the
"sigcontext_struct", and you'll see that it mostly *is* x86 regs.

Then, looking in the CLISP source (specifically,
"clisp-1996-05-30/unix/sigsegv.c", a file well worth reading for
its insights into this very issue) I see that on Linux the signal
handlers are called with a signal number and a "sigcontext_struct"
inline, and that the "cr2" word (the last word in that struct) is
the one you want.

Give that a try [and then mail me if it doesn't work, no point in
cluttering up this group until we have an answer]...


-Rob

-----
Rob Warnock, 8L-855		rpw3@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-964-0811
Mountain View, CA  94043	PP-ASEL-IA