Adjustments for Windows x64 SEH

Hi,

at AdaCore, we are now using native SEH exceptions for Windows x64 based on Richard's patch

 http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01966.html

I plan to submit a rebased version of this work soon, but we have found a few issues in the port:

* Registers cannot be pushed once the frame pointer is set.  Otherwise the unwinder is not able to read the old values.

* There was no protection against very large frame size.  We have a few tests declaring huge local array (> 2 GB) for the purpose of testing stack checking.  Without rework, this created either ICE or gas errors, because unwind info cannot handle such large values or because an extra register is needed to save or spill a register.  I fixed this issue by allocating a small area just to save the registers and then allocating the remaining.  There is no unwind info emitted for the second (and large) area, as if it were allocated by alloca.

* In order to implement setjmp/longjmp via RtlUnwindEx, we need to pass to setjmp the value of the establish frame address for the current function.  I added for this purpose a new builtin (__builtin_establisher_frame).  This was manually tested by building and using gdb which uses setjmp/longjmp internally for its exception mechanism.

Bootstrapped and regtested on x86_64 GNU/Linux.

Comments are welcome.

Tristan.

2012-06-18  Tristan Gingold  <gingold@adacore.com>

	* doc/extend.texi (X86 Built-in Functions): Document
	__builtin_establisher_frame.
	* config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ...
	(seh_cfa_adjust_cfa): ... that function.
	(seh_emit_stackalloc): Do not emit out of range values.
	* config/i386/i386.md: Delete unused UNSPEC_REG_SAVE,
	UNSPEC_DEF_CFA constants.
	Add UNSPEC_ESTABLISHER_FRAME.
	(establisher_frame): Add insn.
	* config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define.
	* config/i386/i386.c (ix86_frame_pointer_required): Required
	for very large frames on SEH target.
	(ix86_compute_frame_layout): Save area is before frame pointer
	on SEH target.  Handle very large frames.
	(ix86_expand_prologue): Likewise.
	(enum ix86_builtins): Add IX86_BUILTIN_ESTABLISHER_FRAME.
	(ix86_init_builtins): Add __builtin_establisher_frame.
	(ix86_expand_builtin): Handle IX86_BUILTIN_ESTABLISHER_FRAME.
	(ix86_output_establisher_frame): New function.
	* config/i386/i386-protos.h (ix86_output_establisher_frame): Declare.

Hello Tristan,

patch works for me, too. Just one nit about the patch.

2012/6/18 Tristan Gingold <gingold@adacore.com>:
> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
>   if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
>     return true;
>
> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
> +     allocation is 4GB (add a safety guard for saved registers).  */
> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
> +    return true;
Where does this magic 4096 comes from?  Is it intended to be the
page-size, or is it meant to be the maximum stack-frame consumed by
prologue?  I would suggest to use here instead:
+  if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - 4096))
+    return true;

Additional a testcase for big-stackframe would be interesting.  You
won't need to make here a execution test, a assembler-scan would be
enough.

On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:

> Hello Tristan,
> 
> patch works for me, too. Just one nit about the patch.
> 
> 2012/6/18 Tristan Gingold <gingold@adacore.com>:
>> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
>>   if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
>>     return true;
>> 
>> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
>> +     allocation is 4GB (add a safety guard for saved registers).  */
>> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
>> +    return true;
> Where does this magic 4096 comes from?  Is it intended to be the
> page-size, or is it meant to be the maximum stack-frame consumed by
> prologue?

It is an upper bound for the maximum stack-frame consumed by prologue.

>  I would suggest to use here instead:
> +  if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - 4096))
> +    return true;
> 
> Additional a testcase for big-stackframe would be interesting.  You
> won't need to make here a execution test, a assembler-scan would be
> enough.

I think that a simple build test should make it.

Thanks,
Tristan.

On 2012-06-18 05:22, Tristan Gingold wrote:
> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
> +     allocation is 4GB (add a safety guard for saved registers).  */
> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
> +    return true;

Elsewhere you say this is an upper bound for stack use by the prologue.
It's clearly a wild guess.  The maximum stack use is 10*sse + 8*int 
registers saved, which is a lot less than 4096.

That said, I'm ok with *using* 4096 so long that the comment clearly
states that it's a large over-estimate.  I do suggest, however, folding
this into the SEH_MAX_FRAME_SIZE value, and expanding on the comment
there.  I see no practical difference between 0x80000000 and 0x7fffe000
being the limit.

> +/* Output assembly code to get the establisher frame (Windows x64 only).
> +   This corresponds to what will be computed by Windows from Frame Register
> +   and Frame Register Offset fields of the UNWIND_INFO structure.  Since
> +   these values are computed very late (by ix86_expand_prologue), we cannot
> +   express this using only RTL.  */
> +
> +const char *
> +ix86_output_establisher_frame (rtx target)
> +{
> +  if (!frame_pointer_needed)
> +    {
> +      /* Note that we have advertized an lea operation.  */
> +      output_asm_insn ("lea{q}\t{0(%%rsp), %0|%0, 0[rsp]}", &target);
> +    }
> +  else
> +    {
> +      rtx xops[3];
> +      struct ix86_frame frame;
> +
> +      /* Recompute the frame layout here.  */
> +      ix86_compute_frame_layout (&frame);
> +
> +      /* Closely follow how the frame pointer is set in
> +	 ix86_expand_prologue.  */
> +      xops[0] = target;
> +      xops[1] = hard_frame_pointer_rtx;
> +      if (frame.hard_frame_pointer_offset == frame.reg_save_offset)
> +	xops[2] = GEN_INT (0);
> +      else
> +	xops[2] = GEN_INT (-(frame.stack_pointer_offset
> +			     - frame.hard_frame_pointer_offset));
> +      output_asm_insn ("lea{q}\t{%a2(%1), %0|%0, %a2[%1]}", xops);

This is what register elimination is for; the value substitution happens
during reload.

Now, one *could* add a new pseudo-hard-register for this (we support as
many register eliminations as needed), but before we do that we need to
decide if we can adjust the soft frame pointer to be the value required.
If so, you can then rely on the existing __builtin_frame_address.  Which
is a very attractive sounding solution.  I'm 99% moving the sfp will work.


r~

On Jun 19, 2012, at 6:47 PM, Richard Henderson wrote:

> On 2012-06-18 05:22, Tristan Gingold wrote:
>> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
>> +     allocation is 4GB (add a safety guard for saved registers).  */
>> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
>> +    return true;
> 
> Elsewhere you say this is an upper bound for stack use by the prologue.
> It's clearly a wild guess.  The maximum stack use is 10*sse + 8*int 
> registers saved, which is a lot less than 4096.
> 
> That said, I'm ok with *using* 4096 so long that the comment clearly
> states that it's a large over-estimate.  I do suggest, however, folding
> this into the SEH_MAX_FRAME_SIZE value, and expanding on the comment
> there.  I see no practical difference between 0x80000000 and 0x7fffe000
> being the limit.

Here is the new comment.  I have reduced the estimation to 256.

/* 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
   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)


> 
>> +/* Output assembly code to get the establisher frame (Windows x64 only).
>> +   This corresponds to what will be computed by Windows from Frame Register
>> +   and Frame Register Offset fields of the UNWIND_INFO structure.  Since
>> +   these values are computed very late (by ix86_expand_prologue), we cannot
>> +   express this using only RTL.  */
>> +
>> +const char *
>> +ix86_output_establisher_frame (rtx target)
>> +{
>> +  if (!frame_pointer_needed)
>> +    {
>> +      /* Note that we have advertized an lea operation.  */
>> +      output_asm_insn ("lea{q}\t{0(%%rsp), %0|%0, 0[rsp]}", &target);
>> +    }
>> +  else
>> +    {
>> +      rtx xops[3];
>> +      struct ix86_frame frame;
>> +
>> +      /* Recompute the frame layout here.  */
>> +      ix86_compute_frame_layout (&frame);
>> +
>> +      /* Closely follow how the frame pointer is set in
>> +	 ix86_expand_prologue.  */
>> +      xops[0] = target;
>> +      xops[1] = hard_frame_pointer_rtx;
>> +      if (frame.hard_frame_pointer_offset == frame.reg_save_offset)
>> +	xops[2] = GEN_INT (0);
>> +      else
>> +	xops[2] = GEN_INT (-(frame.stack_pointer_offset
>> +			     - frame.hard_frame_pointer_offset));
>> +      output_asm_insn ("lea{q}\t{%a2(%1), %0|%0, %a2[%1]}", xops);
> 
> This is what register elimination is for; the value substitution happens
> during reload.
> 
> Now, one *could* add a new pseudo-hard-register for this (we support as
> many register eliminations as needed), but before we do that we need to
> decide if we can adjust the soft frame pointer to be the value required.
> If so, you can then rely on the existing __builtin_frame_address.  Which
> is a very attractive sounding solution.  I'm 99% moving the sfp will work.

Thank you for this idea.  I am trying to implement it.

Tristan.

On Jun 19, 2012, at 6:47 PM, Richard Henderson wrote:

> On 2012-06-18 05:22, Tristan Gingold wrote:
>> +/* Output assembly code to get the establisher frame (Windows x64 only).
>> +   This corresponds to what will be computed by Windows from Frame Register
>> +   and Frame Register Offset fields of the UNWIND_INFO structure.  Since
>> +   these values are computed very late (by ix86_expand_prologue), we cannot
>> +   express this using only RTL.  */
>> +
>> +const char *
>> +ix86_output_establisher_frame (rtx target)
>> +{
>> +  if (!frame_pointer_needed)
>> +    {
>> +      /* Note that we have advertized an lea operation.  */
>> +      output_asm_insn ("lea{q}\t{0(%%rsp), %0|%0, 0[rsp]}", &target);
>> +    }
>> +  else
>> +    {
>> +      rtx xops[3];
>> +      struct ix86_frame frame;
>> +
>> +      /* Recompute the frame layout here.  */
>> +      ix86_compute_frame_layout (&frame);
>> +
>> +      /* Closely follow how the frame pointer is set in
>> +	 ix86_expand_prologue.  */
>> +      xops[0] = target;
>> +      xops[1] = hard_frame_pointer_rtx;
>> +      if (frame.hard_frame_pointer_offset == frame.reg_save_offset)
>> +	xops[2] = GEN_INT (0);
>> +      else
>> +	xops[2] = GEN_INT (-(frame.stack_pointer_offset
>> +			     - frame.hard_frame_pointer_offset));
>> +      output_asm_insn ("lea{q}\t{%a2(%1), %0|%0, %a2[%1]}", xops);
> 
> This is what register elimination is for; the value substitution happens
> during reload.
> 
> Now, one *could* add a new pseudo-hard-register for this (we support as
> many register eliminations as needed), but before we do that we need to
> decide if we can adjust the soft frame pointer to be the value required.
> If so, you can then rely on the existing __builtin_frame_address.  Which
> is a very attractive sounding solution.  I'm 99% moving the sfp will work.

One possibly naive question: the current code to expand __builtin_frame_address is:

  /* For a zero count with __builtin_return_address, we don't care what
     frame address we return, because target-specific definitions will
     override us.  Therefore frame pointer elimination is OK, and using
     the soft frame pointer is OK.

     For a nonzero count, or a zero count with __builtin_frame_address,
     we require a stable offset from the current frame pointer to the
     previous one, so we must use the hard frame pointer, and
     we must disable frame pointer elimination.  */
  if (count == 0 && fndecl_code == BUILT_IN_RETURN_ADDRESS)
    tem = frame_pointer_rtx;
  else
    {
      tem = hard_frame_pointer_rtx;

      /* Tell reload not to eliminate the frame pointer.  */
      crtl->accesses_prior_frames = 1;
    }

So whatever we do with the sfp, the builtin will always returns %rbp - which is not what we expect.

This however opens two tracks:

1) Implement the __builtin_establisher_frame with frame_pointer_rtx
2) If accesses_prior_frames is set, makes %rbp be the establisher frame.

I will pursue the later.

Tristan.

On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:

> Hello Tristan,
> 
> patch works for me, too. Just one nit about the patch.
> 
> 2012/6/18 Tristan Gingold <gingold@adacore.com>:
>> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
>>   if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
>>     return true;
>> 
>> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
>> +     allocation is 4GB (add a safety guard for saved registers).  */
>> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
>> +    return true;
> Where does this magic 4096 comes from?  Is it intended to be the
> page-size, or is it meant to be the maximum stack-frame consumed by
> prologue?  I would suggest to use here instead:
> +  if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - 4096))
> +    return true;
> 
> Additional a testcase for big-stackframe would be interesting.  You
> won't need to make here a execution test, a assembler-scan would be
> enough.

I suppose this is checked by large-frame.c.  But it requires lp64; what is the correct writing to enable this test only on 64bit mode ?

Tristan.

2012/6/25 Tristan Gingold <gingold@adacore.com>:
>
> On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:
>
>> Hello Tristan,
>>
>> patch works for me, too. Just one nit about the patch.
>>
>> 2012/6/18 Tristan Gingold <gingold@adacore.com>:
>>> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
>>>   if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
>>>     return true;
>>>
>>> +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
>>> +     allocation is 4GB (add a safety guard for saved registers).  */
>>> +  if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE)
>>> +    return true;
>> Where does this magic 4096 comes from?  Is it intended to be the
>> page-size, or is it meant to be the maximum stack-frame consumed by
>> prologue?  I would suggest to use here instead:
>> +  if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - 4096))
>> +    return true;
>>
>> Additional a testcase for big-stackframe would be interesting.  You
>> won't need to make here a execution test, a assembler-scan would be
>> enough.
>
> I suppose this is checked by large-frame.c.  But it requires lp64; what is the correct writing to enable this test only on 64bit mode ?
>
> Tristan.

You can check for Windows 64-bit targets by 'llp64'.  Check is in
target-supports.exp

Kai