RFC: Two small remote protocol extensions
Andrew Cagney
ac131313@cygnus.com
Fri May 3 13:07:00 GMT 2002
>
> 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
More information about the Gdb
mailing list