Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 28 Apr 2005 17:02:56 +0200 | From | Bodo Stroesser <> | Subject | Re: [uml-devel] Re: Again: UML on s390 (31Bit) |
| |
Bodo Stroesser wrote: > Martin Schwidefsky wrote: > >> So (!entryexit & regs->gprs[2] < 0) translates to the debugger changed >> the >> guest >> system call to something illegal on the first of the two ptrace calls. So >> the >> patch doesn't hurt for normal, non-ptraced operation but it might hurt >> other >> users of ptrace. > > I don't think, it hurts. If a debugger willingly sets the syscall number > to -1, what would happen without the patch? > The kernel will set the result -ENOSYS into grps[2]. So, even if trap > still indicates a syscall and a signal is pending, no syscall restarting > will be done. > With the patch, a debugger would observe changed behavior of the kernel > *only*, if it writes the syscall number to -1 on the first syscall > interception and then writes the result to ERESTARTXXXXX on the second, > while at the same time a signal is pending for the debugged process. > > I assumed, that non of the current users of ptrace exactly does this. > If I'm wrong here, the patch *really* is bad. Addendum: To avoid any conflicts as far as possible, the -1 written and checked as the syscall number to reset trap could be replaced by some magic value, which then should defined in asm/ptrace.h In terms of performance, any method, that allows to reset trap without an additional ptrace call, is fine.
Bodo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |