Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
> On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
>> You are loosing EAX in the process.
>
> When would this matter? EAX is a scratch register per ABIs, no?

You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example.

Le 14/03/2012 14:43, FeepingCreature a écrit :
> On 03/14/12 12:13, deadalnix wrote:
>> Le 13/03/2012 23:24, Vladimir Panteleev a écrit :
>>> I think something like this needs to end up in Druntime, at least for
>>> Linux x86 and x64.
>>
>> You are loosing EAX in the process.
> It's somewhat unavoidable. One way or another, you need to find _some_ threadlocal spot to stick those extra size_t.sizeof bytes, since you mustn't lose data, but the hack works by _overwriting_ the return address.

Thread local storage is a very easy thing in D. Can't we just use a static variable and set from within the signal handler ?

Le 14/03/2012 17:34, Vladimir Panteleev a écrit :
> On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote:
>> Sweet. Yeah, I think you need to use naked and reconstruct the
>> stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI.
>
> I think it might be safe to just reconstruct the stack frame in the
> signal handler, and set gregs[REG_EIP] to &_d_throw directly. It should
> also use a pre-allocated exception object (like how it's done with
> OutofMemoryError and InvalidMemoryOperationError), in case there's data
> corruption in the GC.

Especially if the signal is sent because of stack overflow !

On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
> Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
>> On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
>>> You are loosing EAX in the process.
>>
>> When would this matter? EAX is a scratch register per ABIs, no?
>
> You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example.

This doesn't have anything to do with turning signals into exceptions.

On Wednesday, 14 March 2012 at 16:39:29 UTC, deadalnix wrote:
> Le 14/03/2012 17:34, Vladimir Panteleev a écrit :
>> On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote:
>>> Sweet. Yeah, I think you need to use naked and reconstruct the
>>> stackframe. Not sure how it'd look; I'm not familiar with the x86_64 ABI.
>>
>> I think it might be safe to just reconstruct the stack frame in the
>> signal handler, and set gregs[REG_EIP] to &_d_throw directly. It should
>> also use a pre-allocated exception object (like how it's done with
>> OutofMemoryError and InvalidMemoryOperationError), in case there's data
>> corruption in the GC.
>
> Especially if the signal is sent because of stack overflow !

Not sure if sarcasm..?

In case of a stack overflow, you can't call _d_throwc (or use the
"throw" statement) anyway.

On Wed, Mar 14, 2012 at 05:39:38PM +0100, deadalnix wrote:
> Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
> >On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
> >>You are loosing EAX in the process.
> >
> >When would this matter? EAX is a scratch register per ABIs, no?
> 
> You may want to return from the function the standard way an resume operations. To implement a moving GC using page protection for example.

I believe the original purpose of this was to catch SIGSEGV and turn it into a thrown Error. So we don't care whether EAX is overwritten since we're never going to return to the code that caused the SEGV; we're just reconstructing the stack frame so that stack unwinding will work correctly when we throw the Error.


T

-- 
People tell me that I'm skeptical, but I don't believe it.

Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
> On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
>> Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
>>> On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
>>>> You are loosing EAX in the process.
>>>
>>> When would this matter? EAX is a scratch register per ABIs, no?
>>
>> You may want to return from the function the standard way an resume
>> operations. To implement a moving GC using page protection for example.
>
> This doesn't have anything to do with turning signals into exceptions.

No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem.

On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote:
> Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
>> On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
>>> Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
>>>> On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
>>>>> You are loosing EAX in the process.
>>>>
>>>> When would this matter? EAX is a scratch register per ABIs, no?
>>>
>>> You may want to return from the function the standard way an resume
>>> operations. To implement a moving GC using page protection for example.
>>
>> This doesn't have anything to do with turning signals into exceptions.
>
> No but this does, make sense to catch segfault and act according to it to implement such a functionality. This is a very close problem.

You can't resume D exceptions.

Le 14/03/2012 18:01, Vladimir Panteleev a écrit :
> On Wednesday, 14 March 2012 at 16:39:29 UTC, deadalnix wrote:
>> Le 14/03/2012 17:34, Vladimir Panteleev a écrit :
>>> On Wednesday, 14 March 2012 at 07:35:50 UTC, FeepingCreature wrote:
>>>> Sweet. Yeah, I think you need to use naked and reconstruct the
>>>> stackframe. Not sure how it'd look; I'm not familiar with the x86_64
>>>> ABI.
>>>
>>> I think it might be safe to just reconstruct the stack frame in the
>>> signal handler, and set gregs[REG_EIP] to &_d_throw directly. It should
>>> also use a pre-allocated exception object (like how it's done with
>>> OutofMemoryError and InvalidMemoryOperationError), in case there's data
>>> corruption in the GC.
>>
>> Especially if the signal is sent because of stack overflow !
>
> Not sure if sarcasm..?
>
> In case of a stack overflow, you can't call _d_throwc (or use the
> "throw" statement) anyway.

You can page protect the last segment of the stack, and unprotect it before throwing.

Le 14/03/2012 18:28, Vladimir Panteleev a écrit :
> On Wednesday, 14 March 2012 at 17:18:06 UTC, deadalnix wrote:
>> Le 14/03/2012 18:00, Vladimir Panteleev a écrit :
>>> On Wednesday, 14 March 2012 at 16:37:45 UTC, deadalnix wrote:
>>>> Le 14/03/2012 17:08, Vladimir Panteleev a écrit :
>>>>> On Wednesday, 14 March 2012 at 11:11:54 UTC, deadalnix wrote:
>>>>>> You are loosing EAX in the process.
>>>>>
>>>>> When would this matter? EAX is a scratch register per ABIs, no?
>>>>
>>>> You may want to return from the function the standard way an resume
>>>> operations. To implement a moving GC using page protection for example.
>>>
>>> This doesn't have anything to do with turning signals into exceptions.
>>
>> No but this does, make sense to catch segfault and act according to it
>> to implement such a functionality. This is a very close problem.
>
> You can't resume D exceptions.

I'm not talking about Exception anymore. In case of Exception, this isn't a problem, but in case of regular return, this is.