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?

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.

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

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

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

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

> thanks for your comments - Josef Ezra

No problem.  Happy that someone else is working on it.

Michael