From: David Hildenbrand <david@redhat.com>
To: Pavel Zbitskiy <pavel.zbitskiy@gmail.com>, qemu-devel@nongnu.org
Cc: qemu-trivial@nongnu.org, Richard Henderson <rth@twiddle.net>,
Alexander Graf <agraf@suse.de>, Cornelia Huck <cohuck@redhat.com>,
"open list:S390" <qemu-s390x@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 5/6] target/s390x: fix PACK reading 1 byte less and writing 1 byte more
Date: Mon, 6 Aug 2018 13:34:29 +0200 [thread overview]
Message-ID: <fedd812b-df9c-b610-c78b-fe02f9869660@redhat.com> (raw)
In-Reply-To: <20180805182832.3012-6-pavel.zbitskiy@gmail.com>
On 05.08.2018 20:28, Pavel Zbitskiy wrote:
> PACK fails on the test from the Principles of Operation: F1F2F3F4
> becomes 0000234C instead of 0001234C due to an off-by-one error.
> Furthermore, it overwrites one extra byte to the left of F1.
>
> Signed-off-by: Pavel Zbitskiy <pavel.zbitskiy@gmail.com>
> ---
> target/s390x/mem_helper.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target/s390x/mem_helper.c b/target/s390x/mem_helper.c
> index 704d0193b5..bacae4f503 100644
> --- a/target/s390x/mem_helper.c
> +++ b/target/s390x/mem_helper.c
> @@ -1019,15 +1019,15 @@ void HELPER(pack)(CPUS390XState *env, uint32_t len, uint64_t dest, uint64_t src)
> len_src--;
>
> /* now pack every value */
> - while (len_dest >= 0) {
> + while (len_dest > 0) {
> b = 0;
>
> - if (len_src > 0) {
> + if (len_src >= 0) {
> b = cpu_ldub_data_ra(env, src, ra) & 0x0f;
> src--;
> len_src--;
> }
> - if (len_src > 0) {
> + if (len_src >= 0) {
> b |= cpu_ldub_data_ra(env, src, ra) << 4;
> src--;
> len_src--;
>
In the SS format with two length fields, and in the
RSL format, L1 specifies the number of additional
operand bytes to the right of the byte designated by
the first-operand address. Therefore, the length in
bytes of the first operand is 1-16, corresponding to a
length code in L1 of 0-15. Similarly, L2. specifies the
number of additional operand bytes to the right of the
location designated by the second-operand address.
Results replace the first operand and are never
stored outside the field specified by the address and
length. If the first operand is longer than the second,
the second operand is extended on the left with zeros
up to the length of the first operand. This extension
does not modify the second operand in storage.
Doesn't this imply that we have always length + 1, and therefore the
current code is fine? ("length code vs length")
(e.g. len_dest = 0 implies one byte?)
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2018-08-06 11:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-05 18:28 [Qemu-devel] [PATCH 0/6] Some improvements in z/Arch instructions support Pavel Zbitskiy
2018-08-05 18:28 ` [Qemu-devel] [PATCH 1/6] target/s390x: add BAL and BALR instructions Pavel Zbitskiy
2018-08-06 10:49 ` David Hildenbrand
2018-08-05 18:28 ` [Qemu-devel] [PATCH 2/6] target/s390x: fix CSST decoding and runtime alignment check Pavel Zbitskiy
2018-08-06 11:05 ` David Hildenbrand
2018-08-05 18:28 ` [Qemu-devel] [PATCH 3/6] target/s390x: fix ipm polluting irrelevant bits Pavel Zbitskiy
2018-08-06 11:18 ` David Hildenbrand
2018-08-06 15:24 ` Richard Henderson
2018-08-05 18:28 ` [Qemu-devel] [PATCH 4/6] target/s390x: add EX support for TRT and TRTR Pavel Zbitskiy
2018-08-05 18:28 ` [Qemu-devel] [PATCH 5/6] target/s390x: fix PACK reading 1 byte less and writing 1 byte more Pavel Zbitskiy
2018-08-06 11:34 ` David Hildenbrand [this message]
2018-08-07 9:42 ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-08-05 18:28 ` [Qemu-devel] [PATCH 6/6] target/s390x: implement CVB, CVBY and CVBG Pavel Zbitskiy
2018-08-06 12:55 ` David Hildenbrand
2018-08-06 15:06 ` [Qemu-devel] [PATCH 0/6] Some improvements in z/Arch instructions support Cornelia Huck
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=fedd812b-df9c-b610-c78b-fe02f9869660@redhat.com \
--to=david@redhat.com \
--cc=agraf@suse.de \
--cc=cohuck@redhat.com \
--cc=pavel.zbitskiy@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=rth@twiddle.net \
/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;
as well as URLs for NNTP newsgroup(s).