Re: tracepoints implementation: bug in byte code generating.

["Josef Ezra" <jezra at emc 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?

 We have multi CPU systems that have local and shared memory spaces that
 can have the same addresses from a pointer point of view.

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

I apologize. I just wanted the chance to play with those commands in my test
environment before suggesting them in this forum.

> 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

Since that has been discussed before, I'll follow the traditional approach.

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

Let me try to list the features that I would like to have, if you think that
other tracepoints clients may be interested, I will be more then happy to
cooperate.

-In actions:
-- Trace/ref different memory ranges.
-- Stop all traces on condition.
-- Save back trace functions chain. (I can't save all the stack, but I can
save a limited array of function addresses)

-In output:
--Show/set memory from different memory space - (already suggested by J.T.C)
--Display (if traced) the functions backtrace array.

-I also need a user interface for conditional trace commands. The Stub
specification has provisions for aop_goto but I could not find a way to
access this through GDB.
-As a reply to "QT_Frame" I would like to get the passcount with the frame
and tracepoint numbers.
-In the future I will like to have a trace/ref of long address with
base-offset parameters.

thanks for your comments - Josef Ezra