Re: More trouble with i386 EFLAGS and ptrace

[Daniel Jacobowitz]

On Sun, Mar 06, 2005 at 07:16:37PM -0800, Roland McGrath wrote:
> > I think mine is more correct; the problem doesn't occur because the
> > debugger cancelled a signal, it occurs because a bogus TF bit was saved
> > to the signal context.  I like keeping solutions close to their
> > problems.  But that's just aesthetic.
> 
> I understand the scenario.  Understanding how it comes about made me
> recognize there is another scenario that is also handled wrong.  
> I didn't say the second scenario was what you are seeing.
> 
> Dan's patch covers the case of PTRACE_SINGLESTEP called to deliver a signal
> that has a handler to run.  That's because there TF is set after the ptrace
> stop, when it's resuming.  This is a "normalize register state" operation.
> I think it would be a little clearer to do this in handle_signal where the
> similar case of tweaking register state to back up a system call is done.
> 
> The patch I posted moves the resetting of TF from the trap handler to
> ptrace_signal_deliver.  This is necessary to ensure that TF is not shown as
> set in the registers retrieved by the debugger when the process stops for
> something other than the single-step trap requested by PTRACE_SINGLESTEP.

Is this semantically different from the patch I posted, i.e. is there
any case which one of them covers and not the other?

> Here is a patch that does both of those things.  This had no effect on any
> of the gdb testsuite cases (for good or ill) aside from sigstep.exp, and:
> 
> $ grep 'FAIL.*sigstep' testsuite/gdb.sum
> KFAIL: gdb.base/sigstep.exp: finish from handleri; leave handler (could not set breakpoint) (PRMS: gdb/1736)
> 
> I don't know what that one is about, but it was KFAIL before the change too.

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!

> 

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/