Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* about QTro packet (tracepoints)
@ 2003-10-01  6:23 ankit thukral
  2003-10-01  6:43 ` Jim Blandy
  0 siblings, 1 reply; 2+ messages in thread
From: ankit thukral @ 2003-10-01  6:23 UTC (permalink / raw)
  To: gdb


 hi all,
        i was reading the packets' format in GDB for
 tracepoints (like QTStart,QTinit etc.) and came
 across
 "QTro" packet format.i learned that this packet
 transmits the addresses of all the LOADABLE
 READ-ONLY
 sections to the remote stub so that the latter can
 always entertain a request for data belonging to
 these
 address ranges,even if this was not specified as a
 tracepoint action by the user.
       would it not be a better option to let the
 remote stub collect this information of it's own
 (from
 it's own copy of the executable) rather than GDB
 transmitting it across the network which definitely
 is
 more costly in terms of time delay suffered by the
 process which becomes all the more costly while
 debugging a real-time application?
 
 hoping for a discussion on this,
 ankit.
 

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: about QTro packet (tracepoints)
  2003-10-01  6:23 about QTro packet (tracepoints) ankit thukral
@ 2003-10-01  6:43 ` Jim Blandy
  0 siblings, 0 replies; 2+ messages in thread
From: Jim Blandy @ 2003-10-01  6:43 UTC (permalink / raw)
  To: ankit thukral; +Cc: gdb

ankit thukral <ankit_plug@yahoo.com> writes:

>  hi all,
>         i was reading the packets' format in GDB for
>  tracepoints (like QTStart,QTinit etc.) and came
>  across
>  "QTro" packet format.i learned that this packet
>  transmits the addresses of all the LOADABLE
>  READ-ONLY
>  sections to the remote stub so that the latter can
>  always entertain a request for data belonging to
>  these
>  address ranges,even if this was not specified as a
>  tracepoint action by the user.
>        would it not be a better option to let the
>  remote stub collect this information of it's own
>  (from
>  it's own copy of the executable) rather than GDB
>  transmitting it across the network which definitely
>  is
>  more costly in terms of time delay suffered by the
>  process which becomes all the more costly while
>  debugging a real-time application?

If you're running Linux or something like that on the target, sure.
But tracepoints also need to work on systems with no operating system
at all, just a stub.  In that case, the stub has no idea which
sections are read-only and which sections may change.

The QTro packet is only sent once, when the trace experiment begins;
is it actually a major time sink?  How many sections do you have?


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-10-01  6:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-01  6:23 about QTro packet (tracepoints) ankit thukral
2003-10-01  6:43 ` Jim Blandy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox