Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313@cygnus.com>]

> 
> There some more annoying things in gdb protocol which require careful
> consideration:
> 
> 1. zbreaks support by kind - how gdb can dynamically learn that particular
>    kind of zbreak is not supported by target

gdb/367

> 2. zbreaks support by count - how gdb can dynamically learn that
>    it is trying to set one zbreak too many.

related to gdb/368

> 3. reconnect - how target could learn that it got a connect from
>    a new session so it has to forget about all zbreaks.

There is a biger bug here.

If the connection is tcp, then the target knows this because the tcp 
connection will have been re-built.

If the connection is serial, however, there is nothing to start / finish 
a session.

created gdb/523

> 4. exact meaning of Hg - last time I checked it was related to registers

It is similar to current frame VS selected frame.

When the target stops, there is single identifyable ``current thread'' 
that is considered responsible for the stop.

The user can then select another thread for examination.  This changes 
the ``selected thread'' but does not affect the ``current thread''.  A 
Hg packet is sent to the target to notify it that a new thread has been 
selected and that this new thread's registers should be operated on by 
the [Gg] and [pP] register packets.

Changing ``selected thread'' does not affect things like the scheduler.

created gdb/524

> 5. exact meaning of Hc - last time I check it did not mean anything
>    because gdb itself was not able to support per thread breakpoints

I believe it is used for a ``thread hop''.  A thread hop occures when 
you want to step just one thread over a breakpoint (without allowing any 
other threads to sneak through).

It doesn't have anything to do with per-thread breakpoints.

created gdb/525(?)

> 6. gdb should be able to switch dynamically to soft-stepping if
>    target does not support steps

gdb/274

> 7. Have configurable option to remove breakpoints before doing steps
> 
> 8. Obsolete 'is-thread-alive'.
> 
> 
> Can somebody write a draft spec so we can discuss it as  a whole,
> naturally, if you want you can start from one written by me but it
> is completely unnesessary - just clean-up the thing to truly usable
> state.

First thing to do, I think, is to rip out the @multitables in the 
current doco.

Andrew