This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: about QTro packet (tracepoints)
- From: Jim Blandy <jimb at redhat dot com>
- To: ankit thukral <ankit_plug at yahoo dot com>
- Cc: gdb at sources dot redhat dot com
- Date: 01 Oct 2003 01:38:40 -0500
- Subject: Re: about QTro packet (tracepoints)
- References: <20031001062341.86372.qmail@web60106.mail.yahoo.com>
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?