Subject: Re: random signals kill my processes with -current
To: Bill Studenmund <firstname.lastname@example.org>
From: John F. Woods <email@example.com>
Date: 01/27/1997 21:25:34
> What if we taked a real guard page to the end of the stack. It would be 4k
> or 8k (whatever is the minimum), and we would fill it with some knowm
> value. Or if there's data stored below the stack, it's just a buffer zone.
> We fill it with a data value which we don't expect to be bassed to a
> subroutine, like a word-unaligned address for an unmapped area. When ever
> we context switch (or at other times like some stage of autoconfig), we
> check to see that the values we stored are still there. If no, something
> went wrong, and we note it.
I was going to suggest this, but decided it was too obvious to mention :-).
However, now that it's been brought up, I'll add the interesting wrinkle
I wanted to ask about: this kind of checking works better the more frequently
you check (obviously); is there any way to convince gcc to alter the function
entry/exit code? In particular, to have it generate a call instruction to
some user-defined functions. This way, you could arrange to check the
signature of the current U area on every function entry and exit. This is
obviously not something you'd want in a production kernel, but could be done
in a debug kernel without a major penalty. (Since gcc doesn't seem to have
this (that I found, anyway), you'd have to add it, and you could add a
#pragma to turn it off for "the next function" to avoid larding up
frequently-called short subroutines.)