From: Andrew Donnellan <andrew.donnellan@au1•ibm.com>
To: oliver <oohall@gmail•com>
Cc: linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH] Fix fall-through from case 30 (rld*) to case 31
Date: Wed, 27 Jan 2016 18:00:37 +1100 [thread overview]
Message-ID: <56A86B15.9040803@au1.ibm.com> (raw)
In-Reply-To: <CAOSf1CEh6GjJZLKGXDviVbycPUuPzb6jL05Zq5d0pzBpeiumNA@mail.gmail.com>
On 27/01/16 16:29, oliver wrote:
>>Is there anywhere else in the sstep code that deals well with malformed instructions?
>
> When you break out of the switch the opcode type is marked as unknown
> and when further attempts to parse the instruction fail it returns zero
> to indicate failure. Also, many of the instructions handled by the
> function are only valid in 64bit mode. For 32bit processors these
> instructions would be illegal and the code that handles them is
> #ifdef`ed out when compiling for 32 bit platforms so simply breaking out
> of the switch and letting it propagate should be the right move here.
analyse_instr() returns 0 whenever it analyses but does not execute an
instruction - it's not a failure as such.
In emulate_step(), if analyse_instr() returns 0 it will test for a bunch
of instruction classes which require memory operations, and classes
which can't be single-stepped. UNKNOWN isn't handled specifically, so
it'll skip all that and return 0 at the end (meaning the step was not
successfully emulated - as opposed to -1, which is used for instructions
that are not allowed to be stepped).
This in turn is handled differently depending on whether emulate_step()
is invoked in the kprobes, uprobes or hw_breakpoint code.
Rather than breaking out and relying on behaviour later in the code, I'd
suggest either:
- creating a goto label for bad instructions that clearly sets the
type to UNKNOWN and returns 0 (and maybe adding some handling for that
in emulate_step(), raise some kind of nice big warning at the very least)
- make analyse_instr() return -1 on invalid instructions, which
emulate_step() will immediately propagate, then make sure that whoever
calls emulate_step() handles that appropriately
Andrew
--
Andrew Donnellan Software Engineer, OzLabs
andrew.donnellan@au1•ibm.com Australia Development Lab, Canberra
+61 2 6201 8874 (work) IBM Australia Limited
next prev parent reply other threads:[~2016-01-27 7:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 6:55 [PATCH] Fix fall-through from case 30 (rld*) to case 31 Oliver O'Halloran
2016-01-27 0:52 ` Andrew Donnellan
2016-01-27 5:29 ` oliver
2016-01-27 7:00 ` Andrew Donnellan [this message]
2016-02-15 23:28 ` [PATCH] powerpc/lib/sstep.c - Fix emulation fall-through Oliver O'Halloran
2016-02-16 0:59 ` Andrew Donnellan
2016-02-16 6:31 ` [PATCH v2] powerpc/sstep.c " Oliver O'Halloran
2016-05-10 21:48 ` [v2] " Michael Ellerman
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=56A86B15.9040803@au1.ibm.com \
--to=andrew.donnellan@au1$(echo .)ibm.com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=oohall@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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