Turning a SIGSEGV into a regular function call under Linux, allowing throw
Steven Schveighoffer
schveiguy at yahoo.com
Wed Mar 14 14:35:04 PDT 2012
On Wed, 14 Mar 2012 17:25:28 -0400, deadalnix <deadalnix at gmail.com> wrote:
> Le 14/03/2012 21:53, Steven Schveighoffer a écrit :
>> On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston <dac at nospam.com> wrote:
>>
>>> On 14/03/12 21:31, Steven Schveighoffer wrote:
>>>> On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston <dac at nospam.com>
>>>> wrote:
>>>>
>>>>> Now, your user space handler will cause another segfault when it does
>>>>> the mov [ESP], 0. I think that gives you an infinite loop.
>>>>
>>>> SEGFAULT inside a SEGV signal handler aborts the program (no way to
>>>> turn
>>>> this off IIRC).
>>>>
>>>> -Steve
>>>
>>> But you're not inside the signal handler when it happens. You returned.
>>
>> Then how does the signal handler do anything? I mean, doesn't it need a
>> stack? Or does it just affect register variables? Most signal handlers
>> are normal functions, and isn't there some usage of the stack to save
>> registers?
>>
>> It seems there should be a way to turn off the signal handler during the
>> time when you are suspicous of the stack being the culprit, then
>> re-engage the signal handler before throwing the error.
>>
>> -Steve
>
> The address of the instruction being executed is hijacked, so, instead
> of resuming normal operation after the signal handler exit, it get into
> the throwing handler.
>
> This is a very nice trick !
I get that. What I was saying is, I thought even the signal handler uses
the stack (thereby it would abort if invalid). And even if it doesn't,
simply accessing the stack by loading it into a register should be
sufficient to "test" and see if the stack is valid to use (i.e. cause
another SEGV inside the signal handler forcing an abort so we don't have
an infinite loop).
I honestly don't know enough to really be discussing, but it seems like a
really neat idea, and I grasp how it works. I just don't know all the
particulars of signal calling conventions.
-Steve
More information about the Digitalmars-d
mailing list