>>>>> On Wed, 01 Jun 2005 01:41:37 -0600, "Jan Beulich" <[hidden email]> 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
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
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
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).