This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: tracepoints implementation: bug in byte code generating.


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

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

I withdraw this suggestion.

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

Do you mean  by walking through every frame? Wouldn't that be too clumsy?

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

I withdraw this suggestion too (unless others are facing the need to capture
64 bits pointers (to another memory space) in 32 bits architecture)

- Josef Ezra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]