From: Keith Owens <kaos@ocs.com.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Incorrect unwind data in entry.S
Date: Sat, 06 Jan 2001 00:51:17 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590678205891@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590678205870@msgid-missing>
On Fri, 5 Jan 2001 10:48:45 -0800,
David Mosberger <davidm@hpl.hp.com> wrote:
>>>>>> On Thu, 21 Dec 2000 14:42:45 +1100, Keith Owens <kaos@ocs.com.au> said:
>
> Keith> The prologue after .ret21 makes no sense. Unwind claims that
> Keith> we are increasing the stack by 416 and spilling registers to
> Keith> stack but we are really removing the struct switch_stack.
>
>The code is correct. A prologue always describes the _current state_
>of the frame, not the _changes_ to the frame (which would make no
>sense). In other words, the code says that after the
>load_switch_stack, the frame is back to the original state (switch
>stack is gone).
Where does it say that a prologue always describes the current state?
I am looking at Intel's IA-64 Software Conventions and Runtime
Architecture Guide, 24535802.pdf, August 2000. Section 11.3
"For the purposes of unwinding, we divide every procedure up into one
or more regions, which are classified as either "prologue" or "body"
regions."
...
"For both types of regions, the unwinder needs to know the state of
the stack frames and preserved registers upon entry to the region.
There are four ways to establish the entry state for an unwind
region:
* The first region in the procedure assumes that both stack frames
are unallocated, and no registers have been saved upon entry to the
region.
* A region may modify the state of the stack frames and preserved
registers; each subsequent region takes the previous region's exit
state as its entry state.
* When control does not flow into a region from directly above it,
the region may specify an alternate predecessor region whose exit
state is used instead.
* Zero-length prologue regions may be inserted just prior to a
prologue or body region to set up the correct entry state."
The first region in a procedure has no initial state, so the first
prologue must describe the current state, we agree on that. The second
point explicitly says that "each subsequent region takes the previous
region's exit state as its entry state", this point makes no
distinction between body and prologue regions.
According to the docs, a second prologue in a procedure should only
modify the existing state, not define the entire state. Either the
documentation is incorrect or the unwind data for the second prologue
in ia64_prepare_handle_unaligned is incorrect.
next prev parent reply other threads:[~2001-01-06 0:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-21 3:42 [Linux-ia64] Incorrect unwind data in entry.S Keith Owens
2001-01-05 18:48 ` David Mosberger
2001-01-06 0:51 ` Keith Owens [this message]
2001-01-06 1:58 ` David Mosberger
2001-01-16 23:41 ` Cary Coutant
2001-01-17 1:34 ` David Mosberger
2001-01-17 18:54 ` Cary Coutant
2001-01-17 20:04 ` David Mosberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-105590678205891@msgid-missing \
--to=kaos@ocs.com.au \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox