* A issue about ptrace/SINGLESTEP on arm64
@ 2017-10-16 4:27 chengjian (D)
2017-10-16 15:30 ` Will Deacon
0 siblings, 1 reply; 4+ messages in thread
From: chengjian (D) @ 2017-10-16 4:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi
I write demo use ptrace/SINGLESTEP to count the number of instructions
executed by the process
The parent process fork+exec a child process, and trace(SINGLESTEP) it,
It works fine under the x86_64 architecture but has an exception under
arm64.
```cpp
//demo.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ptrace.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#ifdef DEBUG
#define dprintf printf
#else
#define dprintf 0 && printf
#endif
int main(int argc, char *argv[])
{
long long counter = 0;
int wait_val;
int pid;
puts("Please wait");
switch (pid = fork()) {
case -1:
perror("fork");
break;
case 0:
ptrace(PTRACE_TRACEME, 0, 0, 0);
execl("/bin/ls", "ls", NULL);
break;
default:
//ptrace(PTRACE_ATTACH, pid, NULL, NULL);
//waitpid(pid, &wait_val, 0);
//while (wait_val == 1407 ) {
while ( 1 )
{
wait(&wait_val);
if(WIFEXITED(&wait_val)) {
break;
}
counter++;
if (ptrace(PTRACE_SINGLESTEP, pid, 0, 0) != 0)
perror("ptrace");
else
dprintf("counter = %lld\n", counter);
}
}
printf("Number of machine instructions : %lld\n", counter);
return 0;
}
```
It run for a long long time and seems never to stop.
./demo /bin/ls
counter = 8033129
counter = 8033130
counter = 8033131
counter = 8033132
counter = 8033133
counter = 8033134
counter = 8033135
counter = 8033136
counter = 8033137
counter = 8033138
counter = 8033139
^C
It return the same results when track other the other C processes
And then I make an assembly demo(just print Hello-World),
It looks just all right
```asm
//hello.s
// as hello.s ?o hello.o
// ld hello.o ?o hello
.text //code section
.globl _start
_start:
mov x0, 0 // stdout has file descriptor 0
ldr x1, =msg // buffer to write
mov x2, len // size of buffer
mov x8, 64 // sys_write() is at index 64 in kernel functions table
svc #0 // generate kernel call sys_write(stdout, msg, len);
mov x0, 123 // exit code
mov x8, 93 // sys_exit() is at index 93 in kernel functions table
svc #0 // generate kernel call sys_exit(123);
.data //data section
msg:
.ascii "Hello, ARM!\n"
len = . - msg
```
./demo ./hello
./hello : hello
Please wait
Hello, ARM!
Number of machine instructions : 8
I want to know what's going on about it, Is this a bug?
^ permalink raw reply [flat|nested] 4+ messages in thread
* A issue about ptrace/SINGLESTEP on arm64
2017-10-16 4:27 A issue about ptrace/SINGLESTEP on arm64 chengjian (D)
@ 2017-10-16 15:30 ` Will Deacon
2017-10-17 2:04 ` chengjian (D)
0 siblings, 1 reply; 4+ messages in thread
From: Will Deacon @ 2017-10-16 15:30 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 16, 2017 at 12:27:17PM +0800, chengjian (D) wrote:
> Hi
> I write demo use ptrace/SINGLESTEP to count the number of instructions
> executed by the process
> The parent process fork+exec a child process, and trace(SINGLESTEP) it,
>
> It works fine under the x86_64 architecture but has an exception under
> arm64.
My guess is that you are getting stuck in an LDXR/STXR loop, which cannot
be stepped. Can you jump the PC once the child appears to be "stuck"?
IIRC, GDB has special heuristics to step through LDXR/STXR critical
sections.
Will
^ permalink raw reply [flat|nested] 4+ messages in thread
* A issue about ptrace/SINGLESTEP on arm64
2017-10-16 15:30 ` Will Deacon
@ 2017-10-17 2:04 ` chengjian (D)
2017-10-17 9:23 ` Will Deacon
0 siblings, 1 reply; 4+ messages in thread
From: chengjian (D) @ 2017-10-17 2:04 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* A issue about ptrace/SINGLESTEP on arm64
2017-10-17 2:04 ` chengjian (D)
@ 2017-10-17 9:23 ` Will Deacon
0 siblings, 0 replies; 4+ messages in thread
From: Will Deacon @ 2017-10-17 9:23 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 17, 2017 at 10:04:00AM +0800, chengjian (D) wrote:
> 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
What is "nop"? What does perf stat say? Does is "ptrace_singlestep"
reporting the number of instructions? Is it a periodic dump, or does it
actually wait for program termination?
> #=======
> #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
I don't really know where to start here. The dynamic execution of a binary
includes branches, loops, libraries etc so of course the dynamic instruction
count is different to the static count of the binary.
> It seems that the child has also been tracked by the parent process
> when it goes into the kernel space.
Ptrace single-step shouldn't step into the kernel.
> Is this what your 'stuck' mean?
> Does all the instructions been tracked in kernel space, or only the
> LDXR/STXR?
Sorry, I don't understand what you're asking here.
Will
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-10-17 9:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-16 4:27 A issue about ptrace/SINGLESTEP on arm64 chengjian (D)
2017-10-16 15:30 ` Will Deacon
2017-10-17 2:04 ` chengjian (D)
2017-10-17 9:23 ` Will Deacon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).