This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Quality Quorum <qqi at theworld dot com>,Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 03 May 2002 16:07:55 -0400
- Subject: Re: RFC: Two small remote protocol extensions
- References: <Pine.SGI.4.40.0205021600151.791800-100000@shell01.TheWorld.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