Re: [libunwind] parse_dynamic using dwarf

[David Mosberger]

>>>>> On Thu, 25 Mar 2004 12:35:13 -0800, Max Asbock <address@hidden> said:

  Max> Currently the parse_dynamic function in Gparser-dwarf.c is not
  Max> implemented.

Yes.

  Max> Assume we have a unw_dyn_op_t op:

  Max> op-> tag == UNW_DYN_SAVE_REG: /* save register to another register
  Max> op-> */
  Max> this could do something like
  Max>          set_reg (sr, op->reg, DWARF_WHERE_REG, op->val);

  Max> UNW_DYN_SPILL_FP_REL: /* frame-pointer-relative reg spill */
  Max> Where do we need this on x86 or x86-64?

  Max> UNW_DYN_SPILL_SP_REL: /* stack-pointer-relative reg spill */
  Max> How about:
  Max>  set_reg (sr, op->reg, DWARF_WHERE_CFAREL, op->val);

I think for DWARF we can use FP_REL _or_ SP_REL.  Either one would do,
but I think CFA is more commonly thought of as the frame-pointer, so
perhaps using FP_REL would be more obvious.

  Max> UNW_DYN_ADD: /* add constant value to a register */ I guess
  Max> this only applies to the stack pointer set_reg (sr,
  Max> DWARF_CFA_OFF_COLUMN, 0, val);

Usually, that's the case, yes.

  Max> UNW_DYN_POP_FRAMES: /* drop one or more stack frames */ Where
  Max> is this needed and would it represent a typical function
  Max> epilogue sequence, i.e leave; ret?

DWARF doesn't really have a concept of nesting, so I think this may
not be needed.

  Max> UNW_DYN_LABEL_STATE: /* name the current state */ ???
  Max> UNW_DYN_COPY_STATE: /* set the region's entry-state */ ???

These two I actually thought a bit already: DWARF only has a stack of
frame states (push/pop), but I think it makes more sense to implement
the more generic label/copy-state.  We can then emulate push/pop on
top of that buy automatically picking a suitable label number (e.g,
first push does a label_state with label 1, second push does a
label_state with label 2, first pop does copy_state label 2, second
pop does copy_state label 1, etc.).

  Max> UNW_DYN_ALIAS: this could do: fetch_proc_info (c, op->val, 1);
  Max> return create_state_record_for (c, sr, op->val);

  Max> I hope this makes some sense and any input is appreciated.

Yes, it all sounds very reasonable.

There is also the issue of how to find the dynamic unwind info list
from an external program.  My idea was to use a similar approach to
the one I'm using on ia64: create a dummy FDE which covers a
zero-length function and then use a new augmentation character
(perhaps 'D') that would provide the pointer-encoding of the list-head
address.

I brought this up with Richard Henderson and he wasn't overly
enthusiastic about the idea, but he also didn't offer a practical
alternative.  But clearly the binutils folks should be
consulted/informed if we choose to use the dummy-FDE approach.

        --david