Re: tracepoints implementation: bug in byte code generating.

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Josef" == Josef Ezra <jezra@emc.com> writes:
>> Any changes to the remote protocol can be discussed
>> on this mailing list.

Josef> Actually I had in mind a 'show protocol version' command (for
Josef> backward compatibility) and a special read memory command (like
Josef> "mxxxx,lll") which can be used at target side for special reads
Josef> (in my case, it will show values in different memory scope).

For better or for worse, the remote protocol is been designed such
that support for individual features can be probed for at run time
instead of having protocol versions.

While I believe that this has allowed new command packets to be added
to the protocol expediently, I also believe that a more formal design
and review may have produced a better overall result.  Even so, if at
all possible, I think your new command should be probed at run time.

Can you offer more details about your command packet?  Is it a varient
of the 'm' command, or a new command?  What exactly do you mean by
different memory scope?  Is there a cooresponding 'M' command to write
memory?

Josef> If it will turn out to be very useful, I will suggest it in
Josef> this forum.

In my remote II protocol spec (which regulars on the list know that
I've been working on-and-off for about a year, but has never been
ready enough to publish :-( ), the read and write memory commands
take a memory space argument.  I was thinking about it being used
(on a target specific basis) for things like the x86 i/o ports or
PCI config space, etc.  I haven't thought about how such things 
would get through GDB to the CLI, but I thought it was important 
enough that the protocol support such things.  

        --jtc

-- 
J.T. Conklin
RedBack Networks