This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [libunwind] Re: ia64 unwind issue
- From: David Mosberger <davidm at napali dot hpl dot hp dot com>
- To: "Jan Beulich" <JBeulich at novell dot com>
- Cc: <wilson at specifixinc dot com>, binutils at sources dot redhat dot com,libunwind at napali dot hpl dot hp dot com
- Date: Thu, 2 Jun 2005 14:17:09 -0700
- Subject: Re: [libunwind] Re: ia64 unwind issue
- References: <s29d1249.084@lyle.provo.novell.com>
- Reply-to: davidm at 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