Re: [libunwind] Re: ia64 unwind issue

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Wed, 01 Jun 2005 01:41:37 -0600, "Jan Beulich" <JBeulich@novell.com> said:

  Jan> mem_stack_f clearly is in conflict with prologue_gr with the psp bit
  Jan> set, since the former implies that psp can be established by just
  Jan> adding a constant to sp, while the latter implies psp to be present in
  Jan> a gr.

Yes.  In the case of my libunwind, a mem_stack_f following a
prologue_gr would completely (and silently) override the effect of
prologue_gr for the stack-pointer.  On the other hand, a mem_stack_v
mereley defines _when_ the stack-pointer got saved (it leaves the
save-location unchanged).

  Jan> As long as the new stack pointer doesn't get established in the
  Jan> prologue, these can still be avoided, and a sole prologue_gr seems
  Jan> sufficient.

A prologue_gr alone certainly can be correct.  The unwinder would just
assume that if the SP-bit is set, the new stack-pointer would get
established at the end of the prologue.

  Jan> This again (to me) hints at prologue_gr only being usable when
  Jan> the saved registers don't get modified during the prologue (and
  Jan> would explain ias' behavior; note that I wasn't even able to
  Jan> make icc emit a prologue_gr, no matter how trivial a function I
  Jan> used).

This question doesn't really affect libunwind, since it's strictly a
question about how assembler-directives get translated into unwind
descriptors.  I have no idea what the authors of the Itanium assembly
language reference guide had in mind and I'm not certainly I want to
get into the middle of this, but here is one thing to consider:

There appears to be no directive to directly emit mem_stack_v alone so
usually the most compact way to encode an SP-save is to use .prologue
imm-mask (to generate a prologue_gr that indicates _where_ it got
saved) followed by a .vframe (to generate a mem_stack_v to indicate
_when_ it got saved; with the redundant psp_gr being optimized away).
So, there is clearly value in allowing this combination, even if the
syntax is a bit awkward (it might have been cleaner to allow an
argumentless .vframe to emit _just_ mem_stack_v).

	--david