Re: ia64 unwind issue

["Jan Beulich" <JBeulich at novell dot com>]

>>> James E Wilson <wilson@specifixinc.com> 31.05.05 22:40:31 >>>
>On Tue, 2005-05-31 at 07:34, Jan Beulich wrote:
>> The Assembly Language Reference Guide, in section 'Stack Unwind Directives Usage Guidelines' says
>> "* The .prologue <imm_mask> directive with the psp bit set and the .vframe
>> directive both define the psp location. Use only one of them."
>
>A few lines above that, it clearly says to emit one of fframe, vframe,
>or vframesp if the procedure creates a stack.  So there seems to be a
>conflict here.  One bullet is telling us to emit it.  One is telling us
>not to.
>
>The duplicate psp save info isn't a problem with gas.  Gas optimizes
>away the duplicate info.
>
>The remaining issue here is whether the mem_stack_f, mem_stack_v
>distinction is important, because prologue_gr does not imply either
>one.  If the unwinder needs this info, then we have to have the vframe
>directive, and the asm lan manual is wrong.

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

>This is a question that only David Mosberger can answer, and he is
>probably not reading this list.  We need to include him on this
>discussion, or take it to another list, like the libunwind mailing list
>(libunwind@linux.hpl.hp.com).

I therefore Cc-ed this list (and retained more of your mail than I would normally have in order to provide better context).

>> but I'd really like to see at least the case caught where they
>>  disagree (and obviously this then also applies to .vframesp, 
>> .vframepsp, and .fframe). 
>
>Yes, giving an error for inconsistencies here would be good.

Good. I have the beginning of this, but before continuing work here I am waiting for your approval (or disapproval) of the large unwind patch I had sent about a week ago.

>> them here]). Since the third bullet item clearly is an 'or' to the 
>> first two ones but on the other hand has nothing to do with these 
>> optimizations you can read the first and second as 'and' or as 
>> 'or'. Depending on that, one would (or would not) consider using 
>> prologue_gr valid with individual (repeated) .save-s valid. In
>> any case (somewhat proving my way of reading) the description 
>> before the bullet items talks about using the shorthand only 
>> for 'low optimization levels', to me providing a hint that 
>> prologue_gr implies the saved registers not getting modified
>> until the end of that prologue region.
>
>I don't get this.  The third bullet is for leaf functions with no stack,
>and indeed, we don't emit unwind info for this case.  This isn't
>relevant to the issue we are discussing.
>
>The second bullet is for the case where all registers are saved before
>any are modified, and says we don't need the .save directives in this
>case.  This is an optimization that isn't implemented in gcc or gas.
>
>The first bullet is for the case where the registers are saved in
>contiguous locals.  This is for prologue_gr.
>
>I see nothing here that strongly implies that the first two bullets are
>related in any way, or that prologue_gr makes the saves redundant. 
>These appear to be two different issues to me.

Generally eliminating .save-s as indicated in the first bullet is always an error; avoiding them may only be considered in the presence of prologue_gr, which is how I see the first and second bullets connected.

>> Yes, indeed. However, table 11-2 in that section doesn't even list
>>  prologue_gr, so I doubt that was being considered when written (and 
>> at least ias already doesn't follow this rule, nor does gas detect 
>> its violation).
>
>prologue_gr is listed in table 11-1, which comes immediately before
>table 11-2.  There is no need to mention it here.  I will concede
>however that it is possible that this is a documentation error not to
>discuss it here.
>
>Gas not warning about absence of one of the mem_stack_f or mem_stack_v
>directives takes us back to the question I asked earlier about whether
>the unwinder needs them, which only David Mosberger can answer.  If the
>unwinder does require them, then perhaps we should give an warning or
>error if one is missing.

As long as the new stack pointer doesn't get established in the prologue, these can still be avoided, and a sole prologue_gr seems sufficient. This again (to me) hints at prologue_gr only being usable when the saved registers don't get modified during the prologue (and would explain ias' behavior; note that I wasn't even able to make icc emit a prologue_gr, no matter how trivial a function I used).

Jan