libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] Updating the stack pointer in dwarf_cursor


From: David Mosberger
Subject: Re: [libunwind] Updating the stack pointer in dwarf_cursor
Date: Tue, 31 Aug 2004 08:49:46 -0700

>>>>> On Fri, 27 Aug 2004 10:52:24 -0700, Max Asbock <address@hidden> said:

  Max> When unwinding unoptimized code on x86_64 the value for RSP in
  Max> dwarf_cursor retains the original value obtained from ucontext and
  Max> doesn't get updated. So if you do
  Max> unw_get_reg (&cursor, UNW_REG_SP, &sp);
  Max> you always get the original value, regardless of which frame you are in.

  Max> Here is why:

  Max> gcc generates:

  Max> call:      push %RIP
  Max> prologue:  pushq %RBP
  Max> movq  %SRSP, %RBP

  Max> the corresponding dwarf unwind info is (use readelf -w=f to see it)
  Max> CIE:
  Max> DW_CFA_def_cfa: r7 ofs 8                  r7 == RSP
  Max> DW_CFA_offset: r16 at cfa-8              r16 == RIP
  Max> FDE:
  Max> DW_CFA_advance_loc: 1 to <x>
  Max> DW_CFA_def_cfa_offset: 16
  Max> DW_CFA_offset: r6 at cfa-16               r6 == RBP
  Max> DW_CFA_advance_loc: 3 to <x+3>
  Max> DW_CFA_def_cfa_reg: r6

  Max> After run_cfi_program ran on these commands the state record says
  Max> CFA is stored in r6 (RBP) offset 8
  Max> r6 (RBP) and r16 (RIP) are stored in memory on the stack
  Max> apply_reg_state then updates the CFA in the cursor as well as RBP and
  Max> RIP, but there is no update to RSP.
  Max> I think we need to somehow relate the CFA and RSP and update RSP
  Max> accordingly (we already do a similar thing for the case when the CFA is
  Max> stored in RSP). I haven't come up with a solution yet, but I will think
  Max> about it some more.

Hmmh, I suspect this should mean that after the prologue, the contents
of RSP is unknown (e.g., alloca() could modify it there would be no
unwind directives to indicate this).  Accessing UNW_X86_64_RSP
probably should return -UNW_EBADREG in that case.

I suspect you should also define UNW_TDEP_SP as UNW_X86_64_CFA,
analogous to the way I did it on x86, since that's the only stack
address that is guaranteed to be known in each frame.

        --david


reply via email to

[Prev in Thread] Current Thread [Next in Thread]