>>> James E Wilson <[hidden email]> 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 >([hidden email]). 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 |
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 |
Free forum by Nabble | Edit this page |