| From: SMTP%"[email protected]" 24-FEB-1997 14:49:59.68
To: [email protected], [email protected], [email protected],
CC:
Subj: Re: Unwind question
In going through alpha_unwind.c, I asked a subset of you about the routine
inst_is_ret():
++++
static unsigned long
inst_is_ret(union alpha_instruction inst, pdsc_register ra_reg)
{
return (inst.j_format.opcode == op_jsr &&
inst.j_format.function == jsr_ret &&
inst.j_format.rb == ra_reg);
} /* inst_is_ret */
----
I noticed that the code did not check for the hint of 0001 for stack frams
procedures, and asked if it should. Mike responded with the mail string
below from August, 1995. It identifies this problem, and also a problem I
did not notice, which is the requirement that the rb field be reg_ra, which
is not required by the calling standard. Ron noted that without looking at
the field definitions, we couldn't be sure it isn't looking at the hint
bits. I did, it isn't. inst.j_format.function is a 2 bit field. Based on
the mail string below, I propose to modify the routine to be this. Please
send me any comments.
-Al
++++
static unsigned long
inst_is_ret(union alpha_instruction inst, pdsc_register ra_reg)
{
return (inst.j_format.opcode == op_jsr &&
inst.j_format.function == jsr_ret &&
(inst.j_format.hint&1) == 1);
} /* inst_is_ret */
----
>Date: Fri, 4 Aug 1995 14:34:34 -0400
>From: hobbs%[email protected]
>To: "[email protected]"@gemgrp.enet.dec.com,
> gemgrp::QUARRY::[email protected]
>Cc: [email protected], [email protected],
> [email protected], [email protected],
> [email protected]
>Subject: Re: need help diagnosing problem only for ev5
>
>Mike:
>
>I did not doubt that the exception code did what you said. I just
>wanted to point out that not looking at the ret hint bits meant that
>this code probably had a bug and would need to be modified. Now that
>you have forwarded me the code for inst_is_ret I can see an additional
>bug that is more serious than the original problem with the hint bits.
>
>The code that you forwarded me tests the b-reg field of the ret
>instruction for being the ra_reg of the procedure descriptor. The
>calling standard says that any register can be used with the ret
>instruction. Kent Glossop informs me that a recent change to GEM
>makes it possible to use a different register in the procedure return.
>There are situations where using a register other than ra_reg can save
>a cycle or two.
>
>The reserved exit sequence is important in two cases: exception
>handler dispatching and stack unwinding. Let us consider the
>following code sequence from the exception dispatching point of view:
>
>l0: mov $22,$26
>l1: ldq $15,32($15)
>l2: lda $30,64($30)
>l3: ret $31,$22,xxxx
>
>In this sequence, ENTRY_RA is $26, SAVE_RA is $22, FP is $15 and SP is
>$30. The compiler uses $22 in the ret instruction because on an EV-4
>this is two cycles faster than using $26 (assuming everything dual
>issues).
>
>Now consider that an exception occurs with the pc pointing to l3 and
>that the signal handler calls the stack based exception mechanism. If
>xxxx is 0000 then the calling standard says that the pc represents an
>current routine and we must call the exception handler associated with
>program counter l3. If xxxx is 0001 then the calling standard says
>the program counter l3 does not represent a current routine and that
>we must *not* use l3 to locate an exception handler. The Calling
>Standard is silent on what to do if xxxx is something other than 0000
>or 0001. I would recommend only testing the low order hint bit for
>this purpose. I would ignore the other 13 bits and leave them for
>future standardization.
>
>The current inst_is_ret routine does not seem to test the hint bits so
>it will cause the wrong exception handler to be called in the
>situation when the hint bits are 0000. Also, the current inst_is_ret
>routine incorrectly tests for inst.j_format.rb == ra_reg so the
>current implementation will call the wrong exception handler in this
>case where the ret instruction is using SAVE_RA instead of ENTRY_RA.
>
>The original problem of not calling the exception handler when the hint
>of 0000 requires calling the handler is not a serious problem. I can
>think of no situation of code written by Digital where this happens
>and I would be surprised if any customer has written such code.
>
>However, the problem of not recognizing the reserved ret instruction
>when the rb register is different from ra_reg is more serious.
>Incorrectly calling a handler in this situation can cause incorrect
>operations to be done by the Fortran, Pascal and Ada handlers.
>Fortunately, exceptions in the reserved procedure exit sequence are
>quite rare since a trapb will guarantee that no arithmetic exception
>can occur there in the case where the routine has an exception
>handler.
>
>We should consider modifying the inst_is_ret routine to no longer test
>for inst.j_format.rb == ra_reg but to instead test for the hint bits
>containing an odd value.
>
>Another question we need answered is what pc value do we use next for
>unwinding or exception dispatching when the current pc is inside a
>reserved procedure exit sequence. I feel that next pc value should be
>be the value in the register specified by the ret instruction in the
>reserved exit sequence. reserved exit sequence. Mark Davis has argued
>that we should use the
>current contents of the ENTRY_RA register as the next pc value. There
>is no difference between these two techniques when the caller and
>callee agree to follow all the calling standard rules. However, if
>the caller and callee have a private agreement that ENTRY_RA need not
>be restored then these two techniques give different answers. The
>calling standard is not clear on which answer to choose.
>
>The problem we have is that the calling standard was written in a
>relatively easy-to-understand way that gives users a tutorial on how
>to do the most common and useful things (just like a programming
>language handbook). We do not have a document that describes the
>calling standard in a difficult-to-understand way that gives precise
>details and rules useful to calling standard "lawyers" (just like a
>programming language standard).
>
>--Steve
>
>To: hobbs%[email protected]
>Cc: [email protected], [email protected],
> [email protected], [email protected], mjr
>Subject: Re: need help diagnosing problem only for ev5
>Date: Fri, 04 Aug 95 17:39:01 -0400
>From: mjr
>
>Thank you very much for this message. Please let me defer
>responding/QARing/resolving on this issue until I can go
>through this in depth.
>
>-mike
>
>
>Date: Tue, 8 Aug 1995 08:56:46 -0400
>From: [email protected] (Ron 603-881-2088; DTN 381-2088
>08-Aug-1995 0839 -0400)
>To: "[email protected]"@ILOVIT.ENET.dec.com
>Cc: [email protected], [email protected],
> "[email protected]"@US2RMC.ENET.dec.com, [email protected]
>om
>Subject: Re: need help diagnosing problem only for ev5
>
>Mike,
>
>I finally had a chance (after returning from vacation) to follow up on
>your
>exchanges with Steve, and I just wanted to confirm that I agree with his
>analysis of the requirements and implications of the Digital UNIX
>calling
>standard. (Except possibly for the suggested "unnecesary" ECO -- that
>part
>I need to reflect on a bit more.)
>
>I also note that the snippet of code you included in one of your
>messages,
>namely:
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>++++++++
>static unsigned long
>inst_is_ret(union alpha_instruction inst, pdsc_register ra_reg)
>{
> return (inst.j_format.opcode == op_jsr &&
> inst.j_format.function == jsr_ret &&
> inst.j_format.rb == ra_reg);
>
>} /* inst_is_ret */
>
>And none of the callers reference the hint bits.
>
>(Goldminor on back *did* reference the lower 16 bits--but only to
>do a shift to get the j_format.function.)
>------------------------------------------------------------------------
>--------
>is not, of itself, sufficient to resolve whether there is a bug in the
>code
>or not. One needs to look at the structure and literal definitions as
>well.
>
>In particular, I would expect that the inst.j_format.function field
>is in fact the entire 16-bit displacement (if following the SRM
>conventions).
>If so, and if jsr_ret is defined to be 0x8001, then I think the code is
>correct. That is, 0x8000 corresponds to the "return" hardware hint from
>displacement<15:14> and 0x0001 corresponds to the software required
>"reserved
>return from stack procedure" from displacement<13:0>.
>
>[Note that the jump format (j_format?) is the same as the memory format
>except that the lower 16-bits *is* the function field.]
>
>Ron
>
>
>
>To: hobbs%[email protected]
>Cc: [email protected], [email protected],
> [email protected], [email protected], mjr
>Subject: Re: need help diagnosing problem only for ev5
>Date: Fri, 04 Aug 95 17:39:01 -0400
>From: mjr
>
>Thank you very much for this message. Please let me defer
>responding/QARing/resolving on this issue until I can go
>through this in depth.
>
>-mike
>
>
>
>
>
>
>
================== RFC 822 Headers ==================
Received: from wa1tyb.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM)
id AA28776; Mon, 24 Feb 1997 14:50:34 -0500
Message-Id: <[email protected]>
X-Sender: [email protected]
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 24 Feb 1997 14:50:29 -0500
To: [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected]
From: Al Simons <[email protected]>
Subject: Re: Unwind question
|
| From: GEMEVN::BRENDER "Ron 603-881-2088; DTN 381-2088 25-Feb-1997 1109 -0400" 25-FEB-1997 11:26:17.73
To: SMTP%"[email protected]"
CC: [email protected],[email protected],BRENDER
Subj: Re: Unwind question
Al,
Ah, yes. I remember that set of exchanges now. Anyways...
1) I believe what you are proposing to do, namely,
- remove the condition for register $26
- add the condition for a hint of 1 (just one bit)
is the right fix at this point in time.
2) Steve has something of a point regarding the ambiguity re use of "the
actual return register" (taken from the ret instruction) vs the ENTRY_RA
register (taken from the procedure descriptor) for propagation of the
unwind, once a return has been properly identified in accordance with 1).
Actually, Call Std section 3.2.6.2.2 is pretty explicit about using
the ENTRY_RA as the actual return register, but this requirement is not
backed up in other sections or by actual need for correctness. This
probably ought to be clarified by the call standard committee...
In short, there is no doubt in my mind that the DU Calling Standard allows
registers other than $26 for the ENTRY_RA and allows registers other than
$26 in a "reserved ret" instruction. The only question, I think, is whether
those must be the same register within a single routine...
Ron
p.s. I trust it is OK to post this exchange, as well as the historical ones
in the Call Standard Notes file?
|