This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch-v2] Adjustments for Windows x64 SEH
On Jun 21, 2012, at 1:57 PM, Václav Zeman wrote:
> On 21 June 2012 09:48, Tristan Gingold wrote:
>> Here is the new version. It is now possible to use __builtin_frame_address (0) to get the current establisher frame thanks to a tiny adjustment.
>>
>> No regressions on x86_64-linux, and an x86_64-windows native gdb can be built and run.
>>
>> Tristan.
>> [...]
>> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
>> index ddb3645..44533e0 100644
>> --- a/gcc/config/i386/i386.h
>> +++ b/gcc/config/i386/i386.h
>> @@ -729,6 +729,18 @@ enum target_cpu_default
>> /* Boundary (in *bits*) on which the incoming stack is aligned. */
>> #define INCOMING_STACK_BOUNDARY ix86_incoming_stack_boundary
>>
>> +/* According to Windows x64 software convention, the maximum stack allocatable
>> + in the prologue is 4G - 8 bytes. Furthermore, there is a limited set of
>> + instructions allowed to adjust the stack pointer in the epilog, forcing the
>> + use of frame pointer for frames larger than 2 GB. This theorical limit
>> + is reduced by 256, an over-estimated upper bound for the stack use by the
>> + prologue.
>> + We define only one threshold for both the prolog and the epilog. When the
>> + frame size is larger than this threshold, we allocate the are to save SSE
> A typo there? s/the are/the area/
Yes, thanks.
>
>> + regs, then save them, and then allocate the remaining. There is no SEH
>> + unwind info for this later allocation. */
>> +#define SEH_MAX_FRAME_SIZE ((2U << 30) - 256)
>> [...]
>
> --
> VZ