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



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