linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jinyang He <hejinyang@loongson.cn>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Burton <paulburton@kernel.org>,
	Jun-Ru Chang <jrjang@realtek.com>
Subject: Re: [PATCH v2 2/4] MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op
Date: Sun, 7 Feb 2021 22:31:38 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.21.2102072200300.35623@angie.orcam.me.uk> (raw)
In-Reply-To: <1611207098-11381-3-git-send-email-hejinyang@loongson.cn>

On Thu, 21 Jan 2021, Jinyang He wrote:

> mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
> mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by

 The minor opcode extension field is comprised of bits 15:6, not 16:7 as 
your description suggests.  Please be accurate with statements.

> shifting u_format.uimmediate by 6 may be affected by sign extension.

 Why?  The `uimmediate' bit-field member is unsigned for a reason.  No 
sign-extension is made on unsigned data with the right-shift operation.

> Thus, take out the 10 bits for comparison.
> 
> Without this patch, errors may occur, such as these bits are all ones.

 How did you come to this conclusion?

> diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> index d737234..74d7fd8 100644
> --- a/arch/mips/kernel/process.c
> +++ b/arch/mips/kernel/process.c
> @@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip)
>  	 * microMIPS is kind of more fun...
>  	 */
>  	if (mm_insn_16bit(ip->word >> 16)) {
> -		if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
> -		    (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
> +		if (ip->mm16_r5_format.opcode == mm_pool16c_op &&
> +		    ip->mm16_r5_format.rt == mm_jr16_op)
>  			return 1;
>  		return 0;
>  	}

 Code style changes should be submitted on their own as separate patches.

> @@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip)
>  	if (ip->r_format.opcode != mm_pool32a_op ||
>  			ip->r_format.func != mm_pool32axf_op)
>  		return 0;
> -	return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op;
> +	return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op;

 You've now excluded JALR.HB, JALRS, and JALRS.HB instructions.  The mask 
was there for a reason.  If you can't be bothered to verify microMIPS 
changes say with QEMU, then at the very least please check documentation.  
The intent of this code is clear and these instructions are even spelled 
out explicitly in the comment at the top.

 Thomas, please revert this change as I can see you've already taken it.  
It's plain wrong.

  Maciej

  reply	other threads:[~2021-02-07 21:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  5:31 [PATCH v2 0/4] MIPS: process: Some fixes and improvements about get_frame_info() Jinyang He
2021-01-21  5:31 ` [PATCH v2 1/4] MIPS: process: Remove unnecessary headers inclusion Jinyang He
2021-01-21  9:28   ` Huacai Chen
2021-01-21  5:31 ` [PATCH v2 2/4] MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op Jinyang He
2021-02-07 21:31   ` Maciej W. Rozycki [this message]
2021-02-08  1:13     ` Jinyang He
2021-02-09 16:14     ` Thomas Bogendoerfer
2021-01-21  5:31 ` [PATCH v2 3/4] MIPS: Fix get_frame_info() handing of function size Jinyang He
2021-01-21  5:31 ` [PATCH v2 4/4] MIPS: Add is_jr_ra_ins() to end the loop early Jinyang He
2021-01-25 11:24 ` [PATCH v2 0/4] MIPS: process: Some fixes and improvements about get_frame_info() Thomas Bogendoerfer

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=alpine.DEB.2.21.2102072200300.35623@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=hejinyang@loongson.cn \
    --cc=jiaxun.yang@flygoat.com \
    --cc=jrjang@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=paulburton@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /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).