On 2022-01-27 13:09, Nicholas Piggin wrote:
Excerpts from naverao1's message of January 25, 2022 8:48 pm:
On 2022-01-25 11:23, Christophe Leroy wrote:
Le 25/01/2022 à 04:04, Nicholas Piggin a écrit :
+Naveen (sorry missed cc'ing you at first)
Excerpts from Christophe Leroy's message of January 24, 2022 4:39
pm:
Le 24/01/2022 à 06:57, Nicholas Piggin a écrit :
As discussed previously
https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/238946.html
I'm wondering whether PPC32 should be returning -1 for syscall
instructions too here? That could be done in another patch anyway.
The 'Programming Environments Manual for 32-Bit Implementations of
the
PowerPC™ Architecture' says:
The following are not traced:
• rfi instruction
• sc and trap instructions that trap
• Other instructions that cause interrupts (other than trace
interrupts)
• The first instruction of any interrupt handler
• Instructions that are emulated by software
So I think PPC32 should return -1 as well.
I agree.
What about the trap instructions? analyse_instr returns 0 for them
which falls through to return 0 for emulate_step, should they
return -1 as well or am I missing something?
Yeah, good point about the trap instructions.
For the traps I don't know. The manual says "trap instructions that
trap" are not traced. It means that "trap instructions that _don't_
trap" are traced. Taking into account that trap instructions don't
trap
at least 99.9% of the time, not sure if returning -1 is needed.
Allthought that'd probably be the safest.
'trap' is a special case since it is predominantly used by debuggers
and/or tracing infrastructure. Kprobes and Uprobes do not allow probes
on a trap instruction. But, xmon can be asked to step on a trap
instruction and that can interfere with kprobes in weird ways.
So, I think it is best if we also exclude trap instructions from being
single stepped.
But then what happens with other instruction that will sparsely
generate
an exception like a DSI or so ? If we do it for the traps then we
should
do it for this as well, and then it becomes a non ending story.
For a DSI, we restart the same instruction after handling the page
fault.
The single step exception is raised on the subsequent successful
completion of the instruction.
Although it can cause a signal, and the signal handler can decide
to resume somewhere else.
If a signal is generated while we are single-stepping, we delay signal
delivery (see uprobe_deny_signal()) until after the single stepping.
For fatal signals, single stepping is disabled before we allow the
signal to be delivered.
Or kernel mode equivalent it can go to a
fixup handler and resume somewhere else.
For kprobes, we do not allow probing instructions that have an extable
entry.
- Naveen
