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