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
