BookE "branch taken" behavior vis-a-vis updating the NIP register

[James Yang]

On Tue, 12 Nov 2013, pegasus wrote:

> So, off I went and downloaded the latest version of 
> arch/powerpc/kernel/traps.c hoping to see those very changes in 
> them. However it didn't match one on one with what was written in 
> that thread. Ditto for the other files in your patch. Looks like 
> your patch didn't make it to upstream but it looks exactly like what 
> I need here. 

The patches were posted RFC -- request for comment.  Thank you for 
posting your comments.


>  So requesting PTRACE_CONT has to happen inside the SIGTRAP signal 
> handler right? 

After you get the SIGTRAP from the branch, yeah.


> Now as for the second patch, as far as I can see, implements the 
> same functionality. However it makes the change permanent and any 
> tool which is used to the NIP pointing to the branch target will be 
> broken.

The second patch places the burden of determining if you are BookE or 
server on the tool.  I feel this is important because the Server and 
Book-E branch exceptions are fundamentally incompatible, and the 
behavior of PTRACE_SINGLEBLOCK can not be made to be identical by the 
kernel for both subarch, so a tool will have to adjust accordingly.


> Anyways, for me either of them will work. But I think the first patch makes
> everyone happy by using the 'addr' field of ptrace. This also means I will
> have to make my (broken) ptrace working which, it seems is not as easy
> adding an enum field as you suggested. May be theres a check somewhere in
> the actual ptrace code which checks for illegal values and hence even after
> adding an enum, it is being reported as illegal in my case. However getting
> that to work is another story.

Actually, I provided the first patch to show why it probably should 
not be done even though technically possible, since it requires ptrace 
API to be extended to now recognize addr field, needs a TIF flag, etc.  
The second patch seems to me more reasonable to support, since nobody 
has come forth to say that there are actually any tools that rely upon 
the existing hack for BookE or even PTRACE_SINGLEBLOCK.  And the 
existing hack's behavior makes things somewhat useless on BookE, as 
you and I have confirmed.

 
> Please confirm my understanding of your patches and since these 
> patches have not made their way to the upstream kernel, will have to 
> use them myself directly. By the way, I'm using 2.6.32.10 (you 
> know..the long-term kernel) and I couldn't find any of your changes 
> in them but then again I couldn't find it in the latest 3.12 version 
> either.


You will have to backport the patches to your kernel if you want to 
use them.  Both patches change the behavior of existing API, and I 
guess we are still waiting to hear if anyone cares which way it should 
be fixed.