Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230327115642.1610-1-cuiyunhui@bytedance.com>
 <d7111158-7e17-4c88-a8c1-a568db5891fa@spud> <CAEEQ3wkKr9NhKwo0O3D=pfi80j7-cup3VgaWuk8vdk87=ryy6g@mail.gmail.com>
 <747a3382-17e7-4167-a1bb-30a9482be4d1@spud>
In-Reply-To: <747a3382-17e7-4167-a1bb-30a9482be4d1@spud>
From:   =?UTF-8?B?6L+Q6L6J5bSU?= <cuiyunhui@bytedance.com>
Date:   Wed, 29 Mar 2023 15:35:26 +0800
Message-ID: <CAEEQ3wm4Ax4v63QVb7NtQp=-HxbKZNAUsQwevBzDs3sX4+pu9w@mail.gmail.com>
Subject: Re: [External] Re: [PATCH] riscv/fault: Dump user opcode bytes on
 fatal faults
To:     Conor Dooley <conor.dooley@microchip.com>
Cc:     Conor Dooley <conor@kernel.org>, paul.walmsley@sifive.com,
        palmer@dabbelt.com, aou@eecs.berkeley.edu,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Conor,

On Wed, Mar 29, 2023 at 2:25=E2=80=AFPM Conor Dooley <conor.dooley@microchi=
p.com> wrote:

>
> Right, I'm trying to figure out of this is another bug in the kernel -
> if you don't have "fd" in riscv,isa in your devicetree then, even if
> CONFIG_FPU is set, none of the FPU code is meant to run, right?

yeah, CONFIG_FPU is set.
In the problem I encountered, the init to be executed in user mode
contained floating-point instructions, which caused an exception.


> What would be nice to have is what the new show_opcodes() function will
> look like ;)

After printing the contents of __show_regs(), this line will continue
to be printed:
Opcode: 53 80 02 f0

It is not just the problem I encountered. When the process exits
unexpected, we all want to know what the instruction that caused the
process exception is.

Thanks,
Yunhui