Re: tracepoints implementation: bug in byte code generating.

[Michael Snyder <msnyder at redhat dot com>]

Josef Ezra wrote:
> 
> ----- Original Message -----
> From: "J.T. Conklin" <jtc@redback.com>
> To: "Josef Ezra" <jezra@emc.com>
> Cc: "Michael Snyder" <msnyder@redhat.com>; <gdb-patches@sources.redhat.com>;
> "ezra, josef" <ezra_josef@emc.com>; <shagam@emc.com>; <sgordon@emc.com>
> Sent: Thursday, October 19, 2000 7:14 PM
> Subject: Re: tracepoints implementation: bug in byte code generating.
> 
> > >>>>> "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
> >
> 
> Hi
> 
> I thought about 'nAAAA,LLLL' and 'NAAAA,LLLL:XXXX' commands as an
> alternative for 'm' and 'M' commands. In my case (EMC SYMMETRIX) it could be
> useful for indicating the target to get those addresses from a different
> memory space. Your idea of having a memory space argument is more general
> and flexible; I will be very happy to use it.

May I ask what your separate memory spaces are?

> (May I have a copy of your remote II protocol spec? Even half-baked, it
> would be of great help.)
> 
> About the "qver" (show-version) command, I need it for the
> set-tracepoint-with-a-byte-code command. I am adding some byte-code-items
> (like trace/ref-from-other-memory-space and stop-tracing-if) to my target
> and I want gdb to determine the target abilities before it creates this
> code.

Are you aware that EMC is not the only user of tracepoints?
I am the maintainer, and I will be far more likely to accept
your changes if you consult with me on the design BEFORE 
you implement.  In particular, I am not impressed with this
idea of querying the target for a version.  This idea has been
proposed and sunk many times over the years.  I don't think
we need it.  The traditional approach is to send a command
to the stub and see if it replies.  All stubs have to be
able to "handle" commands that they don't understand (by 
sending back an empty reply).  Is there anything about
your new feature that would preclude this?  Is there anything
about your new feature that OTHER tracepoint clients might
not be interested in incorporating?

Michael