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


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


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