Re: tracepoints implementation: bug in byte code generating.

[Michael Snyder <msnyder at redhat dot com>]

> 
> > Since this discussion now involves only tracepoints,
> > after this reply I will continue it in private email
> > unies someone on the list pipes up and expresses an
> > interest in keeping it public.  OK with you Josef?
> >

Putting gdb-patches back IN the Cc: list, at one reader's
request.  Oh well...  ;-)

> > Josef Ezra wrote:
> > >
> > > 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.
> >
> > 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.


> > > -- Stop all traces on condition.
> >
> > That would be useful, sure.
> >
> > > -- Save back trace functions chain. (I can't save all the stack,
> > > but I can save a limited array of function addresses)
> >
> > Tracepoints can already do that.  I do it regularly in demos.
> > All you need to do is define a memory range relative to the
> > stack pointer register.  Capture all that memory, and you can
> > do backtraces, examine the local variables of your caller,
> > and pretty much everything else you would expect.
> >
> This might me perfect for most targets, but in our environment there are big
> stack gaps every time C function is calling assembly function and vice
> versa. Dedicating most of the trace buffer to save the stack, I can't back
> trace more then two or three functions. I considered that as a way to
> compress backtrace data (paying the price of losing information).

Then just collect two chunks of memory instead of one.
Trace can already do that, it doesn't need a special 
extension.  If we start putting in everybody's idea 
of an extension that benefits only one target, we're
gonna end up with a mess.

There's always gonna be a limit to how much stack you can
collect.  You only have so much room in your collection
buffer.  If you want to be able to trace back more than
a few stack levels, it will of course cost you, no matter
what kind of standard or non-standard stack you have.

> > > -In output:
> > > --Show/set memory from different memory space - (already suggested by
> J.T.C)
> >
> > Fine, but not related to traceipoints.
> >
> > > --Display (if traced) the functions backtrace array.
> >
> > Can already do that.  See above.
> >
> > > -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.
> >
> > If you mean something like:
> > if (a == b) then collect c
> > yes, we'd like to have that.
> >
> > If you mean something like
> > if (a == b) then activate tracepoint N
> > then yes, we'd like to have that too.
> 
> Well, I had meant the first 'cause it can be done with the existing byte
> code, but having the other one could be nice too.
> 
> >
> > > -As a reply to "QT_Frame" I would like to get the passcount with the
> frame
> >
> > Hitcount, I assume you mean.  Passcount is something different.
> > Yes, I'm sure we'd like that too.
> >
> > With all of these, however, we would have to talk about
> > the syntax for the remote protocol.  We would not want
> > new syntax to break old existing stubs or debuggers.
> >
> > > and tracepoint numbers.
> >
> > Mmmmm... do we need that?  The frame info ALWAYS contains
> > the PC, and the PC would generally uniquely identify a
> > tracepoint.
> >
> 
> I guess I haven't thought enough about this one. How a different probed able
> command that will return list of tracepoints with their hitcounts?  Would it
> be too noisy?

You can do that now, I think.  Well, you could, if you just
had the hitcounts.  It's just a matter of processing the data
once you get it.  You can either write gdb scripts or tcl/tk
code to produce whatever kind of report or display you  want.

> > > -In the future I will like to have a trace/ref of long address with
> > > base-offset parameters.
> >
> > Have to explain to me what you mean.
> 
> Oh', it is just a special-trace-64-bits and special-trace-ref-64-bits
> commands for letting the target know it has to use bigger address. (in my
> case it means the target should pop two items from the stack instead of
> one). At the gdb side the user should be able to determine separately the
> base and the offset address.

I don't understand -- is this another reference to your separate
address spaces?  If the target architecture supports long pointers
and short pointers, then GDB should already know about that
(although I can't think of an architecture for which this is true.)

I think you need to make this concept into something that can
be supported in the C expression language.  Trace should 
support anything that can be expressed as a C expression.

> > > thanks for your comments - Josef Ezra
> >
> > No problem.  Happy that someone else is working on it.
> >
> > Michael
> >
> Josef