using tracepoints function with both host and target on same computer

using tracepoints function with both host and target on same computer

[Benjamin Tze-Kit Lee]

Hi all,

I am trying to use the tracepoints function from GDB on a program in the
computer.  But the tracepoints function only works on a remote target.
Is there a way that I can configure so that I can use GDB to trace an exec
that's on the same computer?

Thank you very much.

Ben

Re: using tracepoints function with both host and target on same computer

[Daniel Jacobowitz]

On Tue, Aug 06, 2002 at 01:34:08PM -0700, Benjamin Tze-Kit Lee wrote:
> Hi all,
> 
> I am trying to use the tracepoints function from GDB on a program in the
> computer.  But the tracepoints function only works on a remote target.
> Is there a way that I can configure so that I can use GDB to trace an exec
> that's on the same computer?
> 
> Thank you very much.

No.  If I have more free time than I expect to (:-) then I would like
to add this to gdbserver; but that won't be for at least six months.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: using tracepoints function with both host and target on same computer

[Eli Zaretskii]

On Tue, 6 Aug 2002, Daniel Jacobowitz wrote:

> If I have more free time than I expect to (:-) then I would like
> to add this to gdbserver; but that won't be for at least six months.

IMHO, tracepoints should really become part of GDB itself, even for 
native debugging.  That would allow us to debug programs where timing is 
critical, such as real-time software, Emacs display engine, etc.  I miss 
that feature a lot.

Re: using tracepoints function with both host and target on same computer

[Daniel Jacobowitz]

On Wed, Aug 07, 2002 at 08:08:54AM +0300, Eli Zaretskii wrote:
> 
> On Tue, 6 Aug 2002, Daniel Jacobowitz wrote:
> 
> > If I have more free time than I expect to (:-) then I would like
> > to add this to gdbserver; but that won't be for at least six months.
> 
> IMHO, tracepoints should really become part of GDB itself, even for 
> native debugging.  That would allow us to debug programs where timing is 
> critical, such as real-time software, Emacs display engine, etc.  I miss 
> that feature a lot.

I agree; but my dream is to get back to modularization so that
gdbserver will use a small library that GDB also uses to do the actual
tracing, and tracepoints can be there.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: using tracepoints function with both host and target on same computer

[William A. Gatliff]

Eli:


> IMHO, tracepoints should really become part of GDB itself, even for 
> native debugging.  That would allow us to debug programs where timing is 
> critical, such as real-time software, Emacs display engine, etc.  I miss 
> that feature a lot.

Wouldn't some kind of stub be present in these situations anyway?  So
it'd still be an implementation concern for the stub...

In fact, I don't see how you could do tracepoints effectively in
anything resembling real time without stub assistance.



b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: using tracepoints function with both host and target on same computer

[Daniel Jacobowitz]

On Wed, Aug 07, 2002 at 09:51:53AM -0500, William A. Gatliff wrote:
> Eli:
> 
> 
> > IMHO, tracepoints should really become part of GDB itself, even for 
> > native debugging.  That would allow us to debug programs where timing is 
> > critical, such as real-time software, Emacs display engine, etc.  I miss 
> > that feature a lot.
> 
> Wouldn't some kind of stub be present in these situations anyway?  So
> it'd still be an implementation concern for the stub...
> 
> In fact, I don't see how you could do tracepoints effectively in
> anything resembling real time without stub assistance.

You don't do them in actual realtime, but neither do you wait for all
of GDB to process the event; you receive the breakpoint, collect
tracepoint data, and immediately resume without touching GDB's event
loop.  It's a little slower than an in-application stub because it has
to use ptrace to read memory/registers, but not substantially slower.

If you need better, you have to link a stub into the application.  I
think we've been investigating a library for that, but I don't know
when/if it'll be available.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: using tracepoints function with both host and target on same computer

[William A. Gatliff]

Daniel:


On Wed, Aug 07, 2002 at 11:01:50AM -0400, Daniel Jacobowitz wrote:
> You don't do them in actual realtime, but neither do you wait for all
> of GDB to process the event; you receive the breakpoint, collect
> tracepoint data, and immediately resume without touching GDB's event
> loop.  It's a little slower than an in-application stub because it has
> to use ptrace to read memory/registers, but not substantially slower.

... except that I don't think you'd want to be doing that across a
9600bps remote link.  Or, you'd at least want to have the option not
to.

> If you need better, you have to link a stub into the application.  I
> think we've been investigating a library for that, but I don't know
> when/if it'll be available.

I'll take additions to gdbstubs.  :^)

I've set out on several occasions to make time to add this feature,
but somehow I keep getting distracted by other fires.  I'm now
available again, but I'm not currently in a position to do it gratis.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: using tracepoints function with both host and target on same computer

[Daniel Jacobowitz]

On Wed, Aug 07, 2002 at 10:21:13AM -0500, William A. Gatliff wrote:
> Daniel:
> 
> 
> On Wed, Aug 07, 2002 at 11:01:50AM -0400, Daniel Jacobowitz wrote:
> > You don't do them in actual realtime, but neither do you wait for all
> > of GDB to process the event; you receive the breakpoint, collect
> > tracepoint data, and immediately resume without touching GDB's event
> > loop.  It's a little slower than an in-application stub because it has
> > to use ptrace to read memory/registers, but not substantially slower.
> 
> ... except that I don't think you'd want to be doing that across a
> 9600bps remote link.  Or, you'd at least want to have the option not
> to.

I was talking about the native case.  If you have a stub, you do it in
the stub.  You do it wherever a trap is handled; in native that's GDB
itself, otherwise it's gdbserver or your target stub.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: using tracepoints function with both host and target on same computer

[William A. Gatliff]

Daniel:


Er, I guess you were clear on that, weren't you?  My bad.

b.g.

On Wed, Aug 07, 2002 at 11:23:46AM -0400, Daniel Jacobowitz wrote:
> On Wed, Aug 07, 2002 at 10:21:13AM -0500, William A. Gatliff wrote:
> > Daniel:
> > 
> > 
> > On Wed, Aug 07, 2002 at 11:01:50AM -0400, Daniel Jacobowitz wrote:
> > > You don't do them in actual realtime, but neither do you wait for all
> > > of GDB to process the event; you receive the breakpoint, collect
> > > tracepoint data, and immediately resume without touching GDB's event
> > > loop.  It's a little slower than an in-application stub because it has
> > > to use ptrace to read memory/registers, but not substantially slower.
> > 
> > ... except that I don't think you'd want to be doing that across a
> > 9600bps remote link.  Or, you'd at least want to have the option not
> > to.
> 
> I was talking about the native case.  If you have a stub, you do it in
> the stub.  You do it wherever a trap is handled; in native that's GDB
> itself, otherwise it's gdbserver or your target stub.
> 
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

-- 
Bill Gatliff
bgat@billgatliff.com