[RFC 0/7 V3]A general notification in GDB RSP

Pedro Alves palves@redhat.com
Mon Nov 19 18:47:00 GMT 2012


Hi Yao,

sorry for the delay.  I've I've been staring at this series for a while,
and I'll have comments to make in the individual patches.  But one general
concern came to me.  There doesn't seem to be any order guarantee
between the different notifications.  IOW, considering the trace-stopped
notification you proposed in a follow-up series. if a given thread
is tracing/running, and it stops tracing, and then hits another event
that should be reported too (e.g., a stop event - breakpoint/signal/etc.),
GDB could see the events as either:

 #1 - trace stopped
 #2 - thread stopped

or:

 #a - thread stopped
 #b - trace stopped

Is that so?  I was trying to convince myself that is okay both
in this particular case and in general, but I'm not really sure.
It sounds like one of those things that might byte back.  I'd like to
hear your (and others', of course) thoughts on this.

On 10/23/2012 12:26 PM, Yao Qi wrote:
> Hello,
> This is the V3 of this patch series, and V2 is here,
> 
>   [RFC 0/6 V2] A general notification in GDB RSP
>   http://sourceware.org/ml/gdb-patches/2012-09/msg00475.html
> 

[IMO, it'd be nice if we took a hint from the kernel folks, and get into
the habit of making vN submissions more self contained (including
an updated rationale, rather than making the reader follow several
hops).]

> Compared with V2, here are some changes,
> 
>   - Don't require gdbserver in async mode in default.
>   - Add more comments in code.

-- 
Pedro Alves



More information about the Gdb-patches mailing list