[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[libunwind] Re: ia64 unwind issue
[libunwind] Re: ia64 unwind issue
Wed, 01 Jun 2005 01:41:37 -0600
>>> James E Wilson <address@hidden> 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
>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
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).
- [libunwind] Re: ia64 unwind issue,
Jan Beulich <=