[PATCH 3/7]: Ping3: Merge from Stack Branch - DWARF2

[H.J. Lu]

Hi Jason,

We made that change to support calling __builtin_eh_return from any functions:

--
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

double g_f = 1.0;

void __attribute__ ((noinline)) __attribute__ ((regparm(2)))
bar(int arg1, int arg2, int arg3, int arg4)
{
   volatile void *s = alloca(arg4);
   if (g_f)
     throw arg1+arg2+arg3+arg4+g_f;
   else
     __builtin_eh_return(arg2, (void *)&arg3);
}

int foo(void)
{
  volatile int a1 = 1;
  volatile int a2 = 2;
  volatile int a3 = 3;
  volatile int a4 = 4;

  try {
        bar(a1, a2, a3, a4);
  }
  catch (...)
  {
    /* If function throwing the exception called __builtin_eh_return,
       stack pointer will not be restored properly. */
    assert (a1 == 1);
    assert (a2 == 2);
    assert (a3 == 3);
    assert (a4 == 4);
  }

  return 0;
}

int main(void)
{
  volatile int dummy;
  dummy = foo();
  return dummy;
}
--

If I understand it correctly, __builtin_eh_return should only be used in
unwind library and there is no need to realign stack for functions which call
__builtin_eh_return. The above testcase is invalid.

Here is the updated patch. Does it look OK?

Thanks.


H.J.
---

2008-06-12  Xuepeng Guo  <xuepeng.guo@intel.com>

	* dwarf2out.c (dw_fde_struct): Add drap_regnum,
	stack_realignment, stack_realign, uses_drap and drap_reg_saved.
	(reg_save_with_expression): New.
	(add_cfi): If stack is realigned, call reg_save_with_expression
	to represent the location of stored vars.
	(dwarf2out_frame_debug_expr): Add rules 16-19 to handle stack
	realign.
	(output_cfa_loc): Handle DW_CFA_expression.
	(based_loc_descr): Update assert for stack realign.
On Thu, Jun 12, 2008 at 7:49 AM, Jason Merrill <jason@redhat.com> wrote:
> Guo, Xuepeng wrote:
>>> Guo, Xuepeng wrote:
>>>>  8048620 <_Z3foov>:
>>>>  8048620:       8d 4c 24 04             lea    0x4(%esp),%ecx
>>>>  8048624:       83 e4 e0                and    $0xffffffe0,%esp
>>>>  8048627:       ff 71 fc                pushl  0xfffffffc(%ecx)
>>>>  804862a:       55                      push   %ebp
>>>>  804862b:       89 e5                   mov    %esp,%ebp
>>>>  804862d:       83 ec 48                sub    $0x48,%esp
>>>> The DRAP register is ecx. Rule 19 is corresponding to asm statement
>
>>> But hold on a minute...we don't want the CFA to point to the realigned
>>> stack pointer, which is what rule 19 is doing; the CFA is supposed to be
>>> a rule for finding the top of the call frame, so in this function rule 4
>>> is doing the right thing, and then rule 16 is messing things up.
>
>>> The DWARF spec says "by definition, the CFA value does not change."
>
>> For cases like the above example, we in fact reproduced the top part of the call frame which included return address and register ebp. So here we updated the cfa.reg to the realigned stack pointer just like we didn't realign the stack. Asm statement 8048620 corresponded to Rule 4. Asm statement 8048624 corresponded to Rule 16. Asm statement 804862b corresponded to Rule 19. In order to describe the call frame exactly, I have to "change" the CFA value in Rule 19 which happened only under the condition that Rule 4 happened firstly.
>
> You're still violating the DWARF standard by changing the value of the
> CFA; it starts out being the $sp on entry to the function, and then
> changes to be $sp after alignment and saving the frame pointer.
>
> It may be appropriate to revise the standard to accommodate this
> situation; the issues
>
> http://dwarfstd.org/ShowIssue.php?issue=020902.1&type=closed
> http://dwarfstd.org/ShowIssue.php?issue=030812.2&type=closed
>
> seem related to the desire to have rules for finding the previous
> frame's SP that aren't just CFA+offset.  But I'm not comfortable
> accepting this without discussing it with the DWARF committee,
> especially since it breaks the unwind information for
> _Unwind_RaiseException and its friends.
>
> Jason
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc-stack-v6-3.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080612/c2cc6579/attachment.txt>