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
