This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ia64 unwind issue


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.

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).

> 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.

> 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.

> 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.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]