Re: tracepoints implementation: bug in byte code generating.

[Michael Snyder <msnyder at redhat dot com>]

Josef Ezra wrote:
> 
> > > > > -In actions:
> > > > > -- Trace/ref different memory ranges.
> > > >
> > > > Not sure what you mean by the above.
> > >
> > > As I mentioned before, our target is working with two memory spaces:
> regular
> > > and shared. It is very common to have a pointer in regular memory that
> > > points to a structure in shared memory which one of it's field is a
> pointer
> > > to different structure in shared memory which I would like to trace.
> > > Something like:
> > > -  Special-trace (from other memory space) X bytes in offset Y from:
> > >      - Special-trace-ref (size is pointer size) in offset Z from:
> > >            - My-regular-memory-pointer
> >
> > If we add support for separate memory spaces to GDB,
> > then I would favor adding it to the traceing syntax
> > as well.  Otherwise not.  I don't want to start throwing
> > a bunch of stuff into trace that would only be supported
> > on this target or that one.  And if GDB can't support
> > multi-address-spaces, then you wouldn't have a standard
> > way to display your results.
> >
> > The whole strength of the tracing implementation,
> > in my opinion, is that it uses the same expression
> > syntax as the rest of GDB.  Therefore whatever data
> > you collect can be used by the rest of GDB without
> > modification.
> >
> 
> What is the appropriate generic interface to trace and show other memory
> spaces? I can use a good advice here.

Well, first we would need a generic interface to DEBUG 
other memory spaces.  That was my point.  Once we had that,
then we would know how to incorporate it into trace.
But gdb is the dog and trace is the tail -- we should 
not have the tail wagging the dog.

Michael