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

[Jason Merrill <jason at redhat dot com>]

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