Date: Thu, 9 Sep 1999 15:36:50 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, marcus@jet.franken.de, FreeBSD-emulation@FreeBSD.ORG, wine-devel@winehq.com Subject: Re: debugger, stepi, c(ontinue) from breakpoint... Message-ID: <Pine.BSF.4.10.9909091500320.14184-100000@alphplex.bde.org> In-Reply-To: <19990908225333.C1394@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Sep 1999, Juergen Lock wrote:
> On Wed, Sep 08, 1999 at 02:33:57PM -0400, Luoqi Chen wrote:
> > >
> > > - if ((frame.tf_eflags & PSL_T) && !(frame.tf_eflags & PSL_VM)) {
> > > + if ((frame.tf_eflags & PSL_T) && !(frame.tf_eflags & PSL_VM) &&
> > > + *callp->sy_call != sigreturn && *callp->sy_call != linux_sigreturn) {
> > > /* Traced syscall. */
> > > frame.tf_eflags &= ~PSL_T;
> > > + /* tell the signal handler this is a trace trap */
> > > + frame.tf_trapno = T_TRCTRAP;
> > > trapsignal(p, SIGTRAP, 0);
This should probably be trapsignal(p, SIGTRAP, T_TRCTRAP). Signal handlers
should examine the signal code (the 3rd arg to trapsignal()) before examining
tf_trapno. It may be a bug to even look at tf_trapno. The signal code is
supposed to be a properly translated version of tf_trapno.
I think the purpose of (original version of the) above code is only to
make a traced syscall stop on return from the syscall and not one
instruction later. However, this is wrong if the trace flag was set
by sigreturn(). Your changes seem to fix this case but break the case
where sigreturn() is being traced but is not responsible for setting the
trace flag. This can probably be fixed by calling trapsignal() if the
trace flag was set on entry to syscall(), not if it set on exit from
syscall().
> > > }
> > >
> > > (so wine must be the first program that handles SIGTAP for itself and
> > > sets the trace bit from a signal handler? :) I Cc'd this to -emulation,
Quite possibly.
> > It seems to me that SIGTRAP is signalled for either a breakpoint or the
> > TF bit in eflags,
>
> Yup!
>
> > so it is probably safe to assume it's a single step
> > unless the trapno is T_BPTTRAP.
We haven't necessarily even seen a trace trap at this point. All we know
is that the trace flag is set. This is certain to be for tracing and not
for a breakpoint :-). The flag means that a trace trap is scheduled, not
that it has occurred.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9909091500320.14184-100000>