Interesting, well with that in hand the following patch seems to work OK;
I can see the MIPS sysdep has a separate implementation of
set_instruction_pointer
that explicitly talks about avoiding PTRACE_SINGLESTEP but it's only MIPS that
does that so far.
Dave
--- a/sysdeps/linux-gnu/trace.c
+++ b/sysdeps/linux-gnu/trace.c
@@ -127,7 +127,7 @@ continue_after_signal(pid_t pid, int signum) {
proc = pid2proc(pid);
if (proc && proc->breakpoint_being_enabled) {
-#if defined __sparc__ || defined __ia64___ || defined __mips__
+#if defined __sparc__ || defined __ia64___ || defined __mips__ || defined
__arm__
ptrace(PTRACE_SYSCALL, pid, 0, signum);
#else
ptrace(PTRACE_SINGLESTEP, pid, 0, signum);
@@ -162,7 +162,7 @@ continue_after_breakpoint(Process *proc, Breakpoint *sbp) {
} else {
debug(DEBUG_PROCESS, "continue_after_breakpoint: pid=%d,
addr=%p", proc->pid, sbp->addr);
proc->breakpoint_being_enabled = sbp;
-#if defined __sparc__ || defined __ia64___ || defined __mips__
+#if defined __sparc__ || defined __ia64___ || defined __mips__ || defined
__arm__
/* we don't want to singlestep here */
continue_process(proc->pid);
#else
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/771805
Title:
[armel] ltrace hangs
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
