[PATCH 0/2] powerpc: Disable syscall emulation and stepping

Christophe Leroy christophe.leroy at csgroup.eu
Tue Jan 25 16:53:08 AEDT 2022



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


More information about the Linuxppc-dev mailing list