* Re: tracepoints implementation: bug in byte code generating.
[not found] ` <008501c03aad$46c9d700$6c219fa8@lss.emc.com>
@ 2000-10-20 12:33 ` J.T. Conklin
2000-11-14 6:04 ` Spec; Was: " Andrew Cagney
0 siblings, 1 reply; 3+ messages in thread
From: J.T. Conklin @ 2000-10-20 12:33 UTC (permalink / raw)
To: Josef Ezra; +Cc: Michael Snyder, gdb, ezra, josef, shagam, sgordon
>>>>> "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
^ permalink raw reply [flat|nested] 3+ messages in thread