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. Or kernel mode equivalent it can go to a fixup handler and resume somewhere else. How are those handled? Thanks, Nick > For most other interrupts (alignment, vsx > unavailable, ...), we end up emulating the single step exception itself > (see emulate_single_step()). So, those are ok if caused by an > instruction > being stepped. > > > - Naveen >