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? >
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. 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. So at the end it's probably ok with return 0, both for them and for traps. Christophe