[PATCH] PR8541; X86: Handle unwind.init and eh.return intrinsics.

[Pasi Parviainen]

On 15.5.2013 14:54, Dimitry Andric wrote:
> On 2013-05-15 02:20, Pasi Parviainen wrote:
>> On 15.5.2013 2:26, Jakob Stoklund Olesen wrote:
> ...
>>> Is it important that the extra registers are not restored in
>>> non-eh.return epilogues? If not, a simpler implementation would
>>> simply spill all callee-saved registers in eh.return functions. This
>>> is essentially the workaround FreeBSD is using now by inserting
>>> inline assembly.
>>
>> Yes, it is important not to restore those registers on non-eh.return
>> epilogues, since restoring those registers might destroy return value of
>> function on those paths (e.g. X86 uses eax and edx registers for
>> exception information, and restoring eax would destroy return value set
>> before epilogue).
>>
>> So considering previous point, workaround used in FreeBSD is also
>> flawed, since it is trashing return values on non-eh.return epilogues :)
>
> Interesting, but we do not seem to see any effect of such thrashing in
> FreeBSD.  It seems that in the relevant cases, libgcc always returns via
> __builtin_eh_return()?  E.g., would the non-eh.return cases not go via a
> different code path?

Yes, the common code path would be trough __builtin_eh_return. But when 
unwinder encounters some exceptional situation/failure, it will return a 
reason code for it. So, now instead of a proper reason code, client of 
unwinder interface will get a more or less random value and this breaks 
API contract between unwinder and its client.

Pasi.