From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755242AbdJQCH2 (ORCPT <rfc822;w@1wt.eu>);
        Mon, 16 Oct 2017 22:07:28 -0400
Received: from szxga04-in.huawei.com ([45.249.212.190]:8460 "EHLO
        szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752608AbdJQCH1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 16 Oct 2017 22:07:27 -0400
Subject: Re: A issue about ptrace/SINGLESTEP on arm64
To: Will Deacon <will.deacon@arm.com>
CC: <catalin.marinas@arm.com>, <oleg@redhat.com>, <linux@armlinux.org.uk>,
        <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        "Xiexiuqi (Xie XiuQi)" <xiexiuqi@huawei.com>,
        Li Bin <huawei.libin@huawei.com>
References: <8ad32f6b-e04d-98f8-d944-7ec3582fbdf4@huawei.com>
 <20171016153055.GD10500@arm.com>
From: "chengjian (D)" <cj.chengjian@huawei.com>
Message-ID: <d8b5e71d-f8db-bee0-dadf-c57724a68daa@huawei.com>
Date: Tue, 17 Oct 2017 10:04:00 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20171016153055.GD10500@arm.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.219.85]
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
        refid=str=0001.0A020201.59E565C6.012D,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0,
        ip=0.0.0.0,
        so=2014-11-16 11:51:01,
        dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fa4349356c53a3e98893d8fe83110679
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



On 2017/10/16 23:30, Will Deacon wrote:
> Can you jump the PC once the child appears to be "stuck"?
>
> IIRC, GDB has special heuristics to step through LDXR/STXR critical
> sections.
The function can be returned, But the number of instructions looks too much
We use objdump to count the assembly code length of the program

#=======
#trace
#=======
ptrace/2-arm64-loop # objdump -d ./nop | wc -l
     115885


ptrace/2-arm64-loop # ./ptrace_singlestep ./nop

     ./nop : nop
     Please wait
     Number of machine instructions : 186688022


/ptrace/2-arm64-loop # ./ptrace_singlestep ./nop

     ./nop : nop
     Please wait
     Number of machine instructions : 103670668


The number of instructions executed twice is not the same

#=======
#trace ls
#=======

ptrace/2-arm64-loop # objdump -d /bin/ls | wc -l
     18095

ptrace/2-arm64-loop # ./ptrace_singlestep /bin/ls
     /bin/ls : ls
     Please wait
     Number of machine instructions : 7718122167


It seems that the child has also been tracked by the parent process
when it goes into the kernel space.

Is this what your 'stuck' mean?
Does all the instructions been tracked in kernel space, or only the 
LDXR/STXR?