This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: skip_inline_frames failed assertion resuming from breakpoint on LynxOS
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 15 Dec 2014 09:58:27 -0500
- Subject: Re: RFC: skip_inline_frames failed assertion resuming from breakpoint on LynxOS
- Authentication-results: sourceware.org; auth=none
- References: <20141120051109 dot GR5774 at adacore dot com> <20141120051223 dot GA23720 at adacore dot com> <546DBA9F dot 9060600 at redhat dot com> <20141120171137 dot GT5774 at adacore dot com> <546F173A dot 3070204 at redhat dot com> <20141213154638 dot GK5457 at adacore dot com> <548EDE03 dot 7090005 at redhat dot com>
> > gdb/gdbserver/ChangeLog:
> >
> > * lynx-low.c (lynx_resume): Use PTRACE_SINGLESTEP_ONE if N == 1.
> > Remove FIXME comment about assumption about N.
> >
> > OK to commit?
>
> Sure, OK.
Thank you, pushed!
> GDB nowadays sends a single vCont packet that both steps thread A,
> continues thread B with a signal and continues all other threads with
> no signal (previously in some cases it'd just lose control of the
> inferior, or deliver the signal to the wrong thread). Something like:
>
> vCont;s:A;C SIG:B;c
[...]
> Couldn't you iterate over the threads, and use PTRACE_STEP_ONE
> for the stepped threads, and PTRACE_CONT_ONE for the others,
> instead of PTRACE_CONT ? For the case above, lynx_resume would
> end up issuing:
>
> PTRACE_STEP_ONE, thread A, sig 0
> PTRACE_CONT_ONE, thread B, sig SIG
> PTRACE_CONT_ONE, thread C, sig 0
> PTRACE_CONT_ONE, thread D, sig 0
Interesting. Do you mean sending those requests without waiting
for the inferior to stop? I'd have to verify that it's possible
to send ptrace requests while the inferior is "in flight", but
wouldn't you then have possible race conditions?
--
Joel