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

["Guo, Xuepeng" <xuepeng dot guo at intel dot com>]

Hello Jason,
Thanks for your review, see my comments below please.
Xuepeng Guo

>-----Original Message-----
>From: Jason Merrill [mailto:jason@redhat.com]
>Sent: 2008年6月7日 0:36
>To: Guo, Xuepeng
>Cc: gcc-patches@gcc.gnu.org; Richard Guenther; Lu, Hongjiu; Jan Hubicka; Ye,
>Joey
>Subject: Re: [PATCH 3/7]: Ping3: Merge from Stack Branch - DWARF2
>
>Guo, Xuepeng wrote:
>>> From: Jason Merrill [mailto:jason@redhat.com]
>>> Also, all these rules seem to assume that the DRAP register will be FP.
>
>> The DRAP register is different from FP. They are used for different
>purpose in our stack realign proposal. Let me explain them through a piece
>of code in prologue:
>>  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
>804862b. We don't assume the DRAP register is FP, we just update the
>cfa.register to FP here.
>
>I see, and this won't be caught by the existing rules because rule 4
>previously set cfa.reg to be %ecx.
>
>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.

>
>>>> +      /* We also need to properly restore the caller's stack pointer.
>>>> +	 But if callee calls __builtin_eh_return, the calculation of
>>>> +	 offset from exception handling function (typically is
>>>> +	 _Unwind_RaiseException) to target function during unwinding
>>>> +	 will conflict with this mechanism.  It will simply set offset
>>>> +	 to zero.  So here if functions call __builtin_eh_return,
>>>> +	 there will be no unwind information for restoring the stack
>>>> +	 pointer.  */
>>> So this will break unwinding in the debugger out of
>>> _Unwind_RaiseException?
>
>This seems to be related to the problem with CFA definition above.
>
You did grasp the point here. This was really related to CFA redefinition above. For cases that realigned the stack meanwhile DRAP register used, we need to explicitly point out how to restore DRAP register and FP register. 

>Jason