Re: ia64 unwind issue

Re: ia64 unwind issue

[Jan Beulich]

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

Re: ia64 unwind issue

[James E Wilson]

On Wed, 2005-06-01 at 00:41, Jan Beulich wrote:
> mem_stack_f clearly is in conflict with prologue_gr with the psp bit set

Yes, I over generalized.  I should have said only that I thought using
prologue_gr with mem_stack_v was OK.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: ia64 unwind issue

[James E Wilson]

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

Re: ia64 unwind issue

[Jan Beulich]

>>> James E Wilson <wilson@specifixinc.com> 26.05.05 01:35:33 >>>
>On Mon, 2005-05-23 at 03:19, Jan Beulich wrote:
>>this (in my opinion validly) states that there shouldn't be a .vframe
>>in a prologue started with .prologue with the psp bit set in the immediate
>>mask
>
>Where exactly do you think it says this?  A .vframe with a .prologue
>with an immediate mask is not redundant.  The .prologue generates a
>prologue_gr unwind record which specifies where the psp register is
>saved.  The .vframe generates mem_stack_v which specifies when it is
>saved.  Both pieces of information are necessary for complete unwind
>info.

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

Of course, one may or may not consider using both is no error when the locations saved to match, 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). The ias folks told me, however, that while they now think that the statements made in that section may not be fully correct, they also don't plan on changing their assembler (so it will continue to issue a prologue_gr with the psp bit set and a psp_gr if they see both directives)...

>Note that the asm language guide says that .vframe generates both
>mem_stack_v and psp_gr.  
>
>prologue_gr is only a short hand that allows one to optimize away the
>psp_gr unwind record in a common case.  It does not make .vframe or the
>mem_stack_v record unnecessary.

This depends on how you read the section 'Conventions for Prologue Regions' in the SCRA, namely the statements regarding using this shorthand (at the end of the section [my version of that doc appearantly doesn't allow me to copy them out, so I'm not quoting 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.

>Another point, in the SCRA section 11.4.2.2 Descriptor Records for
>Prologue Regions, in the definition for the 't' field, it says that any
>procedure with a memory stack frame must have either a mem_stack_f or
>mem_stack_v.  This contradicts your statement that the .vframe and the
>mem_stack_v unwind record must not be present.

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

>> While both gas and ias don't enforce that rule, ias generates a psp_gr
>> unconditionally when seeing .vframe

>Then ias is generating unnecessary debug info.  You should report this
>bug to Intel.  This is only a quality of implementation issue though,
>not a deviation from the standard.

Unless, as pointed out above, prologue_gr and psp_gr disagree about where psp is saved.

Jan

Re: ia64 unwind issue

[James E Wilson]

On Mon, 2005-05-23 at 03:19, Jan Beulich wrote:
>this (in my opinion validly) states that there shouldn't be a .vframe
>in a prologue started with .prologue with the psp bit set in the immediate
>mask

Where exactly do you think it says this?  A .vframe with a .prologue
with an immediate mask is not redundant.  The .prologue generates a
prologue_gr unwind record which specifies where the psp register is
saved.  The .vframe generates mem_stack_v which specifies when it is
saved.  Both pieces of information are necessary for complete unwind
info.

Note that the asm language guide says that .vframe generates both
mem_stack_v and psp_gr.  

prologue_gr is only a short hand that allows one to optimize away the
psp_gr unwind record in a common case.  It does not make .vframe or the
mem_stack_v record unnecessary.

Another point, in the SCRA section 11.4.2.2 Descriptor Records for
Prologue Regions, in the definition for the 't' field, it says that any
procedure with a memory stack frame must have either a mem_stack_f or
mem_stack_v.  This contradicts your statement that the .vframe and the
mem_stack_v unwind record must not be present.

>(it should also put the same restriction on .save ar.pfs, .save rp, and .save pr).

Likewise, this is wrong.  Ordinarily each one of these will expand to
two unwind records, one which says where the register is saved, and one
which says when it was saved.  Both pieces of info are necessary.

When prologue_gr is used, we already know where the registers are saved,
so we only need one unwind record that says when it is saved.  This is
just an optimization to reduce the size of the unwind info.  The info on
where the register was saved is still necessary with the prologue_gr
unwind record.

The same SCRA section I mentioned above says that if the time is not
specified, then the unwinder should assume that the register is not
modified during the prologue.  This seems to apply to the pfs, rp, and
pr cases.  That is, if we don't modify them during the prologue, then we
can omit the .save unwind directives for them.  This however is merely
an optimization to reduce the size of the unwind info.  There is nothing
wrong with have this additional unnecessary info when the registers
aren't modified during the prologue.

> While both gas and ias don't enforce that rule, ias generates a psp_gr
> unconditionally when seeing .vframe

Then ias is generating unnecessary debug info.  You should report this
bug to Intel.  This is only a quality of implementation issue though,
not a deviation from the standard.

Early versions of gas had the same problem, i.e. we emitted duplicate
unwind records with prologue_gr, but we noticed the problem and fixed
it.  This was fixed 2000-08-07.

You didn't mention it, but I assume that ias is also unconditionally
emitting a mem_frame_v unwind record.  If it isn't, then this is a
serious bug that needs to be fixed.

>whereas gas only generates a mem_stack_v (which is supposedly pointless
>because the use of .prologue <imm>, <gr> implies that the saved registers
>don't get modified until the end of that prologue region).

Why do you think that when prologue_gr is used, the saved registers are
not modified until the end of the prologue region?  I haven't seen
anything about that in the documentation.

prologue_gr is only a short hand that allows one to specify where some
registers are being saved, which allows us to reduce the size of the
unwind info in the common case.  But we still need to specify when they
are being saved.

Again, we can refer to the same SCRA section mentioned above.  If a
register has no time info listed for it, then we can assume it isn't
modified until after the end of that prologue region.  This is merely an
optional optimization to reduce the size of the unwind info.  It is not
a requirement.

> Now modifying gas' behavior seems difficult, because gcc appearantly
> relies on the ability to emit both .prologue with operands and .vframe
> and/or any of the above mentioned .save-s, and I'm fairly certain gcc
> would not actually enforce no modification to these saved registers
> before the end of the prologue.

I haven't seen any convincing evidence that there is anything wrong with
gcc.

For linux, our golden standard for unwind info if David Mosberger's
libunwind package, which contains an unwind library, and a testsuite to
test it (and thus indirectly test the compiler's support for generating
unwind info).  One of the things that this can do is single step through
a program, and try to unwind at every instruction.  This has found a
number of unwind related bugs in gcc/as/libunwind.  We are fairly
confident that the unwind support is in good shape.

It is possible that we are emitting some extra unnecessary info here.  I
don't believe we are doing anything that conflicts with the
documentation.

The extra unnecessary info could be optimized away with some gcc work.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

ia64 unwind issue

[Jan Beulich]

In the IA64 Software and Runtime Architecture Guide there is a (sub-)section "Stack Unwind Directives Usage Guidelines". While not really complete (and perhaps also not fully correct), this (in my opinion validly) states that there shouldn't be a .vframe in a prologue started with .prologue with the psp bit set in the immediate mask (it should also put the same restriction on .save ar.pfs, .save rp, and .save pr). While both gas and ias don't enforce that rule, ias generates a psp_gr unconditionally when seeing .vframe, whereas gas only generates a mem_stack_v (which is supposedly pointless because the use of .prologue <imm>, <gr> implies that the saved registers don't get modified until the end of that prologue region).

Now modifying gas' behavior seems difficult, because gcc appearantly relies on the ability to emit both .prologue with operands and .vframe and/or any of the above mentioned .save-s, and I'm fairly certain gcc would not actually enforce no modification to these saved registers before the end of the prologue.

The question thus is: Should this remain non-compliant? Or does anyone have an idea of how to fix this to both satisfy gcc and meet the spec's requirements?

Jan