Messages in this thread | | | Date | Tue, 8 Mar 2005 19:12:55 -0500 | From | Daniel Jacobowitz <> | Subject | Re: More trouble with i386 EFLAGS and ptrace |
| |
On Mon, Mar 07, 2005 at 01:29:12PM -0800, Roland McGrath wrote: > > Is this semantically different from the patch I posted, i.e. is there > > any case which one of them covers and not the other? > > Yes, the second case that I described when I said there were two cases! > (Sheesh.)
Calm down, there were already two cases. I reread your message and couldn't pick out the answer, or I wouldn't have asked.
> To repeat, when the process was doing PTRACE_SINGLESTEP and then > stops on some other signal rather than because of the single-step trap > (e.g. single-stepping an instruction that faults), ptrace will show TF set > in its registers. With my patch, it will show TF clear.
I can reproduce this problem with the patch that Linus committed, so you should probably update your patch for a current snapshot and nag him about it.
> > That is an inability to set breakpoints in the vsyscall page. Andrew > > told me (last May, wow) that he thought this worked in Fedora, but I > > haven't seen any signs of the code. It would certainly be a Good Thing > > if it is possible! > > Fedora kernels use a normal mapping (with randomized location) for the > page, rather than the fixed high address in the vanilla kernel. The > FIXADDR_USER_START area is globally mapped in a special way not using > normal vma data structures, and is permanently read-only in all tasks. > COW via ptrace works normally for Fedora's flavor, but no writing is ever > possible to the fixmap page.
Blech. I assume that there is no way to map a normal VMA over top of the fixed page, for a particular process? This makes debugging the vsyscall DSO a real pain.
-- Daniel Jacobowitz CodeSourcery, LLC - 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/
| |