This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: breakpoint extension for remote protocol, take II


>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> o the breakpoint protocol be made official
Andrew> 		using the ``z/Z'' character (think cntrl-z)

Andrew> 		GDB would also get a command allowing it to
Andrew> 		use ``b/B'' as a compatibility character.

As far as I'm concerned, there is no reason to maintain b/B for
backwards compatibility.  I deliberately avoided adding the breakpoint
extensions to production code until the specification was settled.

Andrew> 		DOES ANYONE OBJECT TO ``[zZ]''?

Not as such.

Andrew> o the ``,LLLL'' be made non-optional.

Andrew> 		For software breakpoints it would indicate the
Andrew> 		size of the instruction (in hex bytes) that
Andrew> 		needs to be patched.

Ugly, but I don't know how to get around it on MIPS/ARM.  Perhaps this
could still be omitted on all of the other architectures that only
have a single breakpoint instruction.  What would be the semantics 
of a request to add a N byte breakpoint when the architecture does
not have a N byte breakpoint instruction?

Andrew> 		J.T. would this break your existing stub code?

Nothing in my stub is in concrete.

Andrew> o the ``LLLL'' for hardware-breakpoints and
Andrew> 		watchpoints be clarified to explain that it
Andrew> 		indicates the region to be watched.

I'd like to make sure the specification is very flexible.  For
example, a processor that didn't support access watchpoints but had
MMU support that could turn off read/write on a page basis could be
used to implement this feature.


However, there is still one problem with my proposal which I have not
had time to address.  As the remote protocol is a datagram protocol
and the breakpoint extension adds run-time state to the stub, there
must be some mechanism to handle dropped and duplicate packets.
Perhaps a sequence number argument needs to be added to the command
and the response.

	Zseq,t,AA..AA,LLLL
	OK<seq>
	ERR<seq>

The same sequence number scheme could be used for this, and any other
stateful commands that might be added in the future.

	--jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]