This is the mail archive of the gdb@sources.redhat.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: tracepoints implementation: bug in byte code generating.


>>>>> "Josef" == Josef Ezra <jezra@emc.com> writes:
Josef> I thought about 'nAAAA,LLLL' and 'NAAAA,LLLL:XXXX' commands as
Josef> an alternative for 'm' and 'M' commands. In my case (EMC
Josef> SYMMETRIX) it could be useful for indicating the target to get
Josef> those addresses from a different memory space. Your idea of
Josef> having a memory space argument is more general and flexible; I
Josef> will be very happy to use it.

Josef> (May I have a copy of your remote II protocol spec? Even
Josef> half-baked, it would be of great help.)

Sure.  

I now see that I didn't make the memory space a required argument of
the fetch/store memory command, but I did put it in as something to
consider.  Now that I know that others need a similar feature, I'll
be sure to change that in the next draft.

I cleaned up some fuzzy thinking, and enclosed the draft at the end 
of this message.  I changed gdb-patches@... to gdb@... in the `Cc:'
line because this is a more of a long term project.  I welcome 
comments from anyone....

Josef> About the "qver" (show-version) command, I need it for the
Josef> set-tracepoint-with-a-byte-code command. I am adding some
Josef> byte-code-items (like trace/ref-from-other-memory-space and
Josef> stop-tracing-if) to my target and I want gdb to determine the
Josef> target abilities before it creates this code.

I really dislike the idea of a new version command within the remote
protocol, as it implies that we'll have to keep up the version scheme
with each change that is made from this point forward.  The probe for
feature mechanism has served well as we've added binary memory write,
target-managed break/watchpoints, etc.  If there must be a version
number, I'd like to see it limited to the tracepoint facility only.

For the time being, I'll let you and Mike hash this out.

        --jtc

REMOTE DEBUG PROTOCOL II --- Draft 0.0

0. ABSTRACT

This document specifies a new debug protocol intended to replace the
Remote Debug Protocol currently used by GDB.  As of this draft, only
the high level commands and responses have been defined.  Low level
details such as packet framing and even data encoding have been left
for future revisions. 

Assumptions that have been made:

  * The protocol is asynchronous.  GDB should be able to fetch and
    store registers and memory, etc. while the target is executing.
    Likewise, the target should be able to send events to GDB at
    any time.

  * The transport layer handles missing, out-of-order, duplicate and
    corrupted packets, presenting a sequential-packet interface to 
    the command layer.

  * The MTU of the transport layer may be less than the MTU of the 
    command layer.  (issue: If register fetch/store is implemented
    like the current remote debug protocol where all registers are
    written at once, this may preclude supporting certain types of
    physical interfaces on some target architectures due to the size
    of the register set)

    - The transport layer is responsible for fragmentation and 
      reassembly of command packets (note: for performance reasons,
      we probably won't reassemble packets.  Instead, a vector of 
      {ptr,len} elements would be passed to the command layer. It
      would decode the commands using scatter-gather aware primitives.)

  * The protocol is for debugging only.  Features like multiplexing
    I/O belong in another protocol (issue: perhaps these features would 
    use the same transport layer.)


1. DEFINITIONS

context		An execution context on the target.  Possible contexts 
		include the system as a whole, threads, processes.

CMTU		Command Maximum Transmission Unit.  The maximum size of
		a command and response packets.  The CMTU is independent 
		of any other MTU used by the lower levels of the protocol.
	
		[ Should the CMTU be required to be large enough to
		hold the contents of all registers?  As long as the
		context is suspended, we are able to fetch or store
		registers in chunks.  On some targets, the size of
		all registers is quite large, which would require 
		very large packets...

		What kind of CMTU negotiation between host and target 
		should there be? ]
		

2. TYPES

Although the encoding for command arguments and responses has not been
determined, a number of data types have been identified.  The command
arguments and responses are defined in terms of these types.

int	An integer
	[ what is the range of this type?  Is it signed or unsigned? ]

addr_t	An address on a target

bp_id_t	breakpoint identifier
	[ A special value is to be reserved for the BP_DELETE command
	  to indicate that all breakpoints should be removed. ]

bp_type_t
	breakpoint type
		0 - software
		1 - hardware
		2 - read watchpoint
		3 - write watchpoint
		4 - access watchpoint.
	[ are there any non-breakpoint "events" that can/should be
	  watched by this mechanism? ]

context_t
	Specifies a context on the target.  This could be the system,
	a process, a thread, etc.

mode_t	Specifies the memory access mode used to read or write memory.
	(default, 8 bit, 16 bit, 32 bit, 64 bit, etc.)

data[]	A array of character data used to transfer memory or register
	contents.

? reg_data
	For some events (signal, exception, breakpoint, etc.) it is
	desirable to return values of some of the target registers --
	usually the program counter, the frame pointer, and the stack
	pointer -- so that GDB does not have to immediately issue a
	fetch register command.


3. COMMAND RESPONSES / ERRORS

A command response is made up of a error code followed by an optional
argument if the error code is "OK".  This argument contains the value
in a "fetch" or "query" type command.

Unlike the current Remote Debug Protocol, this protocol precisely
identifies errors.

	0 - OK
	1 - invalid command
	2 - invalid arguments
	3 - invalid context
	4 - memory access error
	5 - no room for breakpoint in breakpoint table


4. COMMANDS


4.1 REGISTER FETCH

input:
	context_t	id;
	int		offset;		offset within register data
	int		length;		length of transfer

output:
	int		status;
	char		data[];

This command may yeild unpredicable results if context <id> has not
been suspended.

issues:
	This assumes a single flat address space for all registers.
	It might be convienent to have separate (but potentially
	overlapping) register files for integer registers, floating
	point registers, system registers, miscellaneous registers,
	etc.  

        For example, one register file could contain the PC, FP, SP,
        and whatever other registers are needed on a particular
	architecture for GDB after a signal/exception/breakpoint
	event.  This would solve the problem of what to return in 
	those events.


4.2 REGISTER STORE

input:
	context_t	id;
	int		offset;		offset within register data
	int		length;		length of transfer
	char		data[];

output:
	int		status;

This command may cause unpredictable behavior if context <id> has not
been suspended.

issues:
	see also register fetch.


4.3 MEMORY FETCH

input:
	context_t	id;
	addr_t		address;	address of transfer
	int		length;		length of transfer
	mode_t		mode;

output:
	int		status;
	char		data[length];

description:
	Returns the contents of the memory region at <address> through
	<address> + <length>.

This command may yeild unpredictable results if all contexts which
access this memory region have not been suspended (unless some mutual
exclusion mechanism is employed).

issues:
	should this command take a "address space" argument?  This
	might be useful for I/O space and bus spaces.  If so, should
	registers simply be considered a "space".


4.4 MEMORY STORE

input:
	context_t	id;
	addr_t		address;	address of transfer
	int		length;		length of transfer
	mode_t		mode;
	char		data[length];

output:
	int		status;

description:
	Writes data[] at <address> through <address> + <length>

This command may cause unpredictable results if all contexts which
access this memory have not been suspended (unless some mutual
exclusion mechanisms is employed).

issues:
	see also memory fetch.


4.5 SUSPEND

input:
	context_t	id;		context to stop

output:
	int		status

description:
	The context specified by <context> is suspended.

Suspending a suspending context is not considered an error.


4.6 CONTINUE

input:
	context_t	id;		context to continue
	
output:
	int		status

description:
	The context specified by <context> is resumed at the place
	where it was stopped.

Continuing a running context is not considered an error.


4.7 STEP

input:
	context_t	id;		context to step
	
output:
	int		status

description:
	The context specified by <context> is stepped one instruction.

issues:
	By adding additional parameters <start> and <end> that would
	describe a memory range, we could implement "step while in
	range" semantics.

	Should targets that do not support an architectural single
	step mechanism be required to support this command?  GDB
	emulates single step by inserting breakpoints at the next
	instruction.  The target debug agent could do the same.


4.8 KILL

input:
	context_t	id;		context to kill

output:
	int		status

description:
	The context specifed by <context> is killed.  If <id> is the
	system context, the target is restarted (or rebooted).


4.9 BP_CREATE

input:
	context_t	id;
	bp_type_t	bp_type;
	addr_t		address;
	int		length;

output:
	int		status;
	bp_id_t		bp_id;

description:
	Create a breakpoint of type <bp_type> at <address>.  If <id>
	is the system context, the breakpoint will be trigger in all
	contexts.

	Returns a unique <bp_id> identifying the breakpoint

issues:
	Should we have additional parameters?
		count - if non zero, the number of times the breakpoint
			is ignored before triggering.
	
		action - flags which indicates whether triggering the 
			 breakpoint suspends the context, notifies the
			 host, etc.

	Note GDB is not able to take advantage of these at this time.
	At the target level, it refers to breakpoints only by address,
	and would be unable to distinguish between a unconditional
	breakpoint and one with a hit count.

4.10 BP_DELETE

input:
	bp_id_t		bp_id;

output:
	int		status;

description:
	Delete the breakpoint specified by <bp_id>.

***



5. EVENTS

The target communicates with the host by sending asynchronous events.

In order to avoid requiring the host to constanly poll for events,
there must be a mechanism for the target to send events or for the
target to notify the host that there are pending events.

[ It's not clear which is superior.  If the target can send
notification, it should not be much more difficult to send the event
itself. ]

issues:
	Should GDB have to register for all events, or are all events
	sent automatically?


5.1 CONTEXT_EXIT

    context_t	id
    int		reason
    int		exit_value;


5.2 EXCEPTION

    context_t	id
    int		exception
    ?		reg_data

    A processor exception has occured.

5.3 SIGNAL

    context_t	context
    int		signal
    ?		reg_data

    A signal has been raised.

5.4 BREAKPOINT

    context_t	id
    bp_t	bp_id
    ?		reg_data

    After a breakpoint is hit, the program counter is set to the
    address of the breakpoint.  A STEP command can be issued to
    step over a breakpoint, all the complicated stuff required 
    to accomplish this must be done in the debug agent.

5.? 

Other possible events:
	 CONTEXT_CREATED: (to notify GDB that a new context has been
			 created).
   

6. LISTS

The host must be able to get various lists of objects from the target:
threads, breakpoints, etc.  Each list is a unbounded, which means that
the entire list may be larger than the CMTU.

One way is a get first, get next mechanism.  A "GET_FIRST" command is
issued to get the first item, and then a "GET_NEXT" command is issued
for each additional item with either the target remembering the next
value or the GET_NEXT command using the previous value as an argument.
Both approaches have problems if the list of items is dynamic.

Another way to accomplish this is to slightly modify the command/
response processing so that one command can have multiple return
values.  

	<- GET_BREAKPOINTS
	-> OK
	-> BP <id>,<type>,<count>,<etc.>
	-> BP <id>,<type>,<count>,<etc.>
	-> BP <id>,<type>,<count>,<etc.>
	-> BP <id>,<type>,<count>,<etc.>
	-> End-of-List Token

If the low level transport supports streaming, the performance should
be quite good.


Yet another way would be a command that instructs the target to issue
events (maybe something like CONTEXT_EXISTS, BREAKPOINT_EXISTS, etc.)
for each item in the list.  The problem with this approach is that the
events are received asynchronously, so if the target is constructing a
list of contexts for a display (show threads), it wouldn't know when
all the events had been received.  


-- 
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]