[Dwarf-Discuss] Possible ambiguity with DW_CFA_remember_state/store_state

[Todd Allen]

This issue was brought up in emails in the dwarf2 mailing list on and around Feb
28, 2001.  There were some editorial changes bandied around, but it seems that
the whole issue was dropped before we released the Dwarf 3 standard.
Regardless, the consensus was that the CFA should be saved and restored.

FWIW, in our compilers, we originally also assumed that the CFA would be saved &
restored by those two operators.  But in Jul 2003, we found that the glibc
exception unwind code that uses the .eh_frame information which parallels the
.debug_frame information had a bug and did not save and restore the CFA.  So we
worked around this by having our compilers set the CFA manually after every
restore just to be safe.

On Fri, Jun 12, 2009 at 07:07:42PM -0400, Cary Coutant wrote:
> In the description of DW_CFA_remember_state, the DWARF3 spec says this:
> 
> >   The DW_CFA_remember_state instruction takes no operands. The required action is to push
> >   the set of rules for every register onto an implicit stack.
> 
> I can't find any text that explicitly says that "every register" is
> intended to include the virtual CFA register itself, but the
> description of the abstract CFI table in Section 6.4.1 subtly implies
> it by including CFA as one of the columns along with all the
> explicitly-numbered registers:
> 
> >   Abstractly, this mechanism describes a very large table that has the following structure:
> >
> >   LOC CFA R0 R1 ... RN
> >   L0
> >   L1
> >   ...
> >   LN
> 
> Unfortunately, these operators were interpreted one way for gcc (save
> the CFA along with all the other registers), and the other way for gdb
> (save only the explicitly-numbered registers, but not the CFA). This
> has caused a regression in the gdb testsuite with a fairly recent
> patch to gcc mainline, and a patch is being submitted to fix gdb based
> on my interpretation that CFA ought to be saved.
> 
> Does anyone disagree with this interpretation? Should we fix gcc instead?
> 
> -cary
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

-- 
Todd Allen
Concurrent Computer Corporation