[llvm-dev] Initial State of the DWARF CFI register states

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: Keno Fischer [mailto:keno at juliacomputing.com]
> Sent: Friday, August 26, 2016 6:28 PM
> To: llvm-dev at lists.llvm.org
> Cc: aprantl at apple.com; Robinson, Paul
> Subject: Initial State of the DWARF CFI register states
> 
> Hi All,
> 
> In reading the DWARF standard, it states with respect to the initial
> disposition of the unwind rules for any particular register:
> 
> > The default rule for all columns before interpretation of
> > the initial instructions is the undefined rule. However,
> > an ABI authoring body or a compilation system authoring body
> > may specify an alternate default value for any or all columns.
> 
> Now, the first question is, do we know of such a definition
> (I'm particularly interested in x86_64 here, but information on
> other architecures would be appreciated as well), either in the ABI
> docs or somewhere in LLVM?

I'm in an airport so don't have time for serious research, but
googling 'dwarf cfi initial state' turned up r200255 which in
turn has a review at reviews.llvm.org/D2597 where Keith Walker
cites an ARM document that might be relevant to this topic.

The "System V Application Binary Interface AMD64 Architecture
Processor Supplement" 0.99.8 doesn't mention anything about this
in the DWARF-specific sections, but other parts of the document
might say things that could imply defaults.
HTH,
--paulr

> 
> Second, if I understand correctly what we're currently doing
> (looking at X86FrameLowering::emitCalleeSavedFrameMoves), is
> that we're looking at the callee saved registers for the current
> frame and emitting cfi instructions if those get saved. That
> seems sensible to me, but would imply that we're assuming that
> the initial state for callee-saved registers is cfi_same_value.
> That seems sensible to me, but if that's the definition, I am
> worried about mixing calling conventions in the same compile
> unit. Should we settle on some definition and add the extra unwind
> info where we deviate (or even better add whatever definition
> we settle on to initial_instructions)?
> 
> CFI clients (gdb, lldb, libunwind, etc.) seem to deviate in how they
> handle this, treating it either as undefined or same_value.
> 
> Thanks,
> Keno