Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver)

[Stan Shebs <stanshebs at earthlink dot net>]

On 10/4/13 10:40 AM, Pedro Alves wrote:

> [...]  Unless perhaps we make GDB
> send a unique id along as well... I think the RSP used to always send
> a sequence number with each packet, and that has been removed a long
> time ago.  I wish I know why it was removed.  It would solve these
> issues.  Maybe we should add it back.

I researched this a bit, since I had the same vague memory, but the
situation is odd.  In 1994, Jim Kingdon documented a $cc:<restofpacket>
at the top of remote.c, as an option that stubs accept, and to this
day the example stubs have their bit of code, but I don't see any
evidence that anything was done in GDB before or since.  (The rationale
may simply have been that the stubs needed to be extended first, this
being before the days of qSupported.)

Sequence numbers don't seem like a great idea, though, potentially
introducing brittleness of various sorts.  Although we didn't really
think about it explicitly at the outset, the remote protocol has
generally evolved in the direction of being stateless; for instance,
we don't send a half-dozen vCont packets that must all be applied
together, we send one packet that includes everything.

Philosophically, this makes sense because real targets are quite
unpredictable - two reads in a row can return different results,
a single-step can result in a dozen new threads, etc.

Another well-known stateless protocol is HTTP, needed due to its
own unpredictabilities (as we all experience every day :-) ).  Now
there are situations where statefulness is useful, which they solve
by using cookies.  In the remote protocol, our analogous situation
is where the target needs to be more like an agent, such as with
tracing, and in those cases we do have identifiers that are
coordinated between host and target, though in a somewhat adhoc
way right now.

I think we could develop the id concept into more of a generic mechanism
that is available for target-side commands, actionpoints in general,
and so forth, perhaps with everything using a single numeric (or
textual?) space, so that "231" can be unambiguously a catchpoint,
rather than either a catchpoint or a trace state variable, depending
on context.

Stan
stan@codesourcery.com