* [RFC] Addition of remote tracepoints to gdb / gdbserver.
@ 2004-01-01 21:33 Ramana Radhakrishnan
2004-01-01 21:47 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2004-01-01 21:33 UTC (permalink / raw)
To: Daniel Jacobowitz, Andrew Cagney, gdb, ankit thukral
Hi All ,
This is a proposal to add support for tracepoints for remote debugging
to gdb / gdbserver. Over the next couple of weeks I will submit patches
to take care of the same. The source for these patches is based on work
done by Ankit Thukral in an internal project with gdb here
at Codito Technologies .This mail is an attempt to summarize the
discussions had on the mailing list so far regarding the same.
Tracepoints require the debuggee to run without being interrupted
since the latency caused by it may defer the behaviour
of the debuggee.Tracepoints are put at various points in the debuggee
and actions are defined for :
1. collecting registers
2. collecting memory regions.
3. evaluating an agent expression and storing the result.
The debuggee stops to collect the data,but that is transparent to the user.
The other changes that we propose to make to
gdbserver include :
* Making gdbserver itself multi-threaded and able to communicate with
gdb and continue to
debug the inferior. This would necessitate a version of libpthread for
the target which anyways would be a transitive dependency
(gdbserver -> libpthread_db ->libpthread) .
* Agent Expression Interpreter for gdbserver.
files modified / to be modified (added / to be added) (directory
gdbserver):
1. remote-tracepoint.c : Routines to take care of tracepoint data
structures / storage.
2. remote-tracepoint.h : Corresponding header files.
3. server.c : Changes to allow gdbserver to be asynch.
4. regcache.c
5. inferiors.c
6.. tracepoint.c (GDB directory).
Mechanism :
We use the same mechanism as is used for breakpoints, the difference
being
in the actions being performed at the corresponding tracepoints.
Collecting data at any tracepoint would stop if
a. any one of the tracepoints has been hit it's respective PASSCOUNT
number of times.
b. the user types TSTOP (from the GDB).
c. the debuggee process finishes.
To have support for making the trace experiment stop whenever the user
asks for it (using TSTOP),a thread was spawned for the same purpose.this
thread would just wait for TSTOP (and reply to any no. of TSTATUS queries)
and return.
Problems Faced:
1. Though the GDB expects the stub to support agent expressions,it
never picks up the corresponding data from the GDBSERVER.for instance,
for a request like :
collect VAR1 + VAR2
It generates some 30 odd bytes of agent expression and sends it
to the GDBSERVER.but at the time of tdump,GDB sends 2 memory requests,
one for each of them,adds them and shows the result.
One more thing about it is that it doesn't work for floating
point variables on the GDB side since there is no floating
point support in the AX-Interpreter.
2. There are 3 ways of collecting Transparent memory regions :
A. Read the data from the executable using the BFD (as suggested by Jim
Blandy
on the mailing list).But right now GDBSERVER doesn't have a BFD so he's
not sure how to get around this problem.
B. Store all the transparent regions transmitted by GDB and read from
memory when GDB requests them.but for this,it is imperative that the
debuggee process doesn't exit.Hence we make the debuggee stop before it
actually finishes up .
C. Restart the debuggee (in case it has exited).The aforesaid memory
regions are available.
Right now,we follow approach (B) of not storing the
addresses of Transparent regions transmitted by GDB but am treating
them as any normal memory request.This requires a change in the QTro
packet sent by the GDB, the additional information being an internal
breakpoint at an address as
the first thing following the "QTro".Right now,the internal breakpoint
is on _FINI().
cheers
Ramana
---
Ramana Radhakrishnan
GNU Tools
Codito Technologies
Pune - India
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC] Addition of remote tracepoints to gdb / gdbserver.
2004-01-01 21:33 [RFC] Addition of remote tracepoints to gdb / gdbserver Ramana Radhakrishnan
@ 2004-01-01 21:47 ` Daniel Jacobowitz
2004-01-01 22:29 ` Ramana Radhakrishnan
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-01-01 21:47 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: Andrew Cagney, gdb, ankit thukral
On Fri, Jan 02, 2004 at 02:59:55AM +0530, Ramana Radhakrishnan wrote:
> Hi All ,
>
> This is a proposal to add support for tracepoints for remote debugging
> to gdb / gdbserver. Over the next couple of weeks I will submit patches
> to take care of the same. The source for these patches is based on work
> done by Ankit Thukral in an internal project with gdb here
> at Codito Technologies .This mail is an attempt to summarize the
> discussions had on the mailing list so far regarding the same.
>
>
>
>
> Tracepoints require the debuggee to run without being interrupted
> since the latency caused by it may defer the behaviour
> of the debuggee.Tracepoints are put at various points in the debuggee
> and actions are defined for :
>
> 1. collecting registers
> 2. collecting memory regions.
> 3. evaluating an agent expression and storing the result.
>
> The debuggee stops to collect the data,but that is transparent to the user.
>
> The other changes that we propose to make to
> gdbserver include :
>
> * Making gdbserver itself multi-threaded and able to communicate with
> gdb and continue to
> debug the inferior. This would necessitate a version of libpthread for
> the target which anyways would be a transitive dependency
> (gdbserver -> libpthread_db ->libpthread) .
Ew. No. There is no reason that communicating with GDB while
debugging requires a multi-threaded debug agent; non-blocking I/O is
quite adequate.
It may be easier to prototype this sort of thing using multiple
threads, but the overhead of using libpthread in the debug agent is
just not acceptable. This will probably require a small finite state
machine, or better use of SIGCHLD.
> * Agent Expression Interpreter for gdbserver.
Yes, certainly.
> Collecting data at any tracepoint would stop if
> a. any one of the tracepoints has been hit it's respective PASSCOUNT
> number of times.
>
> b. the user types TSTOP (from the GDB).
>
> c. the debuggee process finishes.
>
>
> To have support for making the trace experiment stop whenever the user
> asks for it (using TSTOP),a thread was spawned for the same purpose.this
> thread would just wait for TSTOP (and reply to any no. of TSTATUS queries)
> and return.
Does the debuggee stop after tstop, or just trace collection stop? I'm
guessing the latter but the GDB manual is not clear.
> Problems Faced:
>
>
> 1. Though the GDB expects the stub to support agent expressions,it
> never picks up the corresponding data from the GDBSERVER.for instance,
> for a request like :
> collect VAR1 + VAR2
>
> It generates some 30 odd bytes of agent expression and sends it
> to the GDBSERVER.but at the time of tdump,GDB sends 2 memory requests,
> one for each of them,adds them and shows the result.
Hmm, that's odd. It should probaby just collect VAR1 and VAR2 in that
case. Does the generated agent expression compute the sum, or does it
compute the location of those variables?
> One more thing about it is that it doesn't work for floating
> point variables on the GDB side since there is no floating
> point support in the AX-Interpreter.
Hmm, this will require extending the AX language, as described in the
manual. Do we need anything other than to treat them as
byte-sequences, though? Theoretically you might want agent expressions
which did something like *(int *)(int)(double) $f0, but in practice I
doubt that is useful.
> 2. There are 3 ways of collecting Transparent memory regions :
>
> A. Read the data from the executable using the BFD (as suggested by Jim
> Blandy
> on the mailing list).But right now GDBSERVER doesn't have a BFD so he's
> not sure how to get around this problem.
>
> B. Store all the transparent regions transmitted by GDB and read from
> memory when GDB requests them.but for this,it is imperative that the
> debuggee process doesn't exit.Hence we make the debuggee stop before it
> actually finishes up .
>
> C. Restart the debuggee (in case it has exited).The aforesaid memory
> regions are available.
>
> Right now,we follow approach (B) of not storing the
> addresses of Transparent regions transmitted by GDB but am treating
> them as any normal memory request.This requires a change in the QTro
> packet sent by the GDB, the additional information being an internal
> breakpoint at an address as
> the first thing following the "QTro".Right now,the internal breakpoint
> is on _FINI().
There are better ways to do this on modern kernels. We should make
gdbserver support that. I can do it later.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Addition of remote tracepoints to gdb / gdbserver.
2004-01-01 21:47 ` Daniel Jacobowitz
@ 2004-01-01 22:29 ` Ramana Radhakrishnan
2004-01-01 22:56 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2004-01-01 22:29 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb, ankit thukral
Daniel Jacobowitz wrote:
>On Fri, Jan 02, 2004 at 02:59:55AM +0530, Ramana Radhakrishnan wrote:
>
>
>>Hi All ,
>>
>>This is a proposal to add support for tracepoints for remote debugging
>>to gdb / gdbserver. Over the next couple of weeks I will submit patches
>>to take care of the same. The source for these patches is based on work
>>done by Ankit Thukral in an internal project with gdb here
>>at Codito Technologies .This mail is an attempt to summarize the
>>discussions had on the mailing list so far regarding the same.
>>
>>
>>
>>
>> Tracepoints require the debuggee to run without being interrupted
>>since the latency caused by it may defer the behaviour
>>of the debuggee.Tracepoints are put at various points in the debuggee
>>and actions are defined for :
>>
>>1. collecting registers
>>2. collecting memory regions.
>>3. evaluating an agent expression and storing the result.
>>
>>The debuggee stops to collect the data,but that is transparent to the user.
>>
>>The other changes that we propose to make to
>>gdbserver include :
>>
>>* Making gdbserver itself multi-threaded and able to communicate with
>>gdb and continue to
>>debug the inferior. This would necessitate a version of libpthread for
>>the target which anyways would be a transitive dependency
>>(gdbserver -> libpthread_db ->libpthread) .
>>
>>
>
>Ew. No. There is no reason that communicating with GDB while
>debugging requires a multi-threaded debug agent; non-blocking I/O is
>quite adequate.It may be easier to prototype this sort of thing using multiple
>threads, but the overhead of using libpthread in the debug agent is
>just not acceptable. This will probably require a small finite state
>machine, or better use of SIGCHLD.
>
>
>
Certainly is .
>>* Agent Expression Interpreter for gdbserver.
>>
>>
>
>Yes, certainly.
>
>
>
>>Collecting data at any tracepoint would stop if
>>a. any one of the tracepoints has been hit it's respective PASSCOUNT
>>number of times.
>>
>>b. the user types TSTOP (from the GDB).
>>
>>c. the debuggee process finishes.
>>
>>
>> To have support for making the trace experiment stop whenever the user
>>asks for it (using TSTOP),a thread was spawned for the same purpose.this
>>thread would just wait for TSTOP (and reply to any no. of TSTATUS queries)
>>and return.
>>
>>
>
>Does the debuggee stop after tstop, or just trace collection stop? I'm
>guessing the latter but the GDB manual is not clear.
>
>
The assumption on our side is that the trace experiment stops and hence
only the trace collection stops. The debuggee continues on its merry
fashion .
>
>
>>Problems Faced:
>>
>>
>>1. Though the GDB expects the stub to support agent expressions,it
>>never picks up the corresponding data from the GDBSERVER.for instance,
>>for a request like :
>> collect VAR1 + VAR2
>>
>> It generates some 30 odd bytes of agent expression and sends it
>>to the GDBSERVER.but at the time of tdump,GDB sends 2 memory requests,
>>one for each of them,adds them and shows the result.
>>
>>
>
>Hmm, that's odd. It should probaby just collect VAR1 and VAR2 in that
>case. Does the generated agent expression compute the sum, or does it
>compute the location of those variables?
>
>
>
The generated Agent expression would compute the sum .
The code generated would look something like what is given in the gdb
manual . This is in contradiction
with what is given in the gdb manual . The manual seems to say that
given a general expression x+y*z the
code generated is (and i quote )
>> One more thing about it is that it doesn't work for floating
>>point variables on the GDB side since there is no floating
>>point support in the AX-Interpreter.
>>
>>
>
>Hmm, this will require extending the AX language, as described in the
>manual. Do we need anything other than to treat them as
>byte-sequences, though? Theoretically you might want agent expressions
>which did something like *(int *)(int)(double) $f0, but in practice I
>doubt that is useful.
>
>
Now the remote side would have to understand the target floating point
format / collect the values for
the same and hence the actual computation would have to be target
specific .2 options
a. do all calculations in gdbserver
b. collect all byte sequences and take care of it in gdb.
Option b seems less expensive.
>
>
>>2. There are 3 ways of collecting Transparent memory regions :
>>
>>A. Read the data from the executable using the BFD (as suggested by Jim
>>Blandy
>>on the mailing list).But right now GDBSERVER doesn't have a BFD so he's
>>not sure how to get around this problem.
>>
>>B. Store all the transparent regions transmitted by GDB and read from
>>memory when GDB requests them.but for this,it is imperative that the
>>debuggee process doesn't exit.Hence we make the debuggee stop before it
>>actually finishes up .
>>
>>C. Restart the debuggee (in case it has exited).The aforesaid memory
>>regions are available.
>>
>> Right now,we follow approach (B) of not storing the
>>addresses of Transparent regions transmitted by GDB but am treating
>>them as any normal memory request.This requires a change in the QTro
>>packet sent by the GDB, the additional information being an internal
>>breakpoint at an address as
>>the first thing following the "QTro".Right now,the internal breakpoint
>>is on _FINI().
>>
>>
>
>There are better ways to do this on modern kernels. We should make
>gdbserver support that. I can do it later.
>
>
>
That'd be PTRACE_EXIT_EVENT in the modern kernels.?Something that I
missed out in my earlier mails.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
Codito Technologies.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Addition of remote tracepoints to gdb / gdbserver.
2004-01-01 22:29 ` Ramana Radhakrishnan
@ 2004-01-01 22:56 ` Daniel Jacobowitz
2004-01-01 23:16 ` Ramana Radhakrishnan
2004-01-03 19:47 ` Ramana Radhakrishnan
0 siblings, 2 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-01-01 22:56 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: Andrew Cagney, gdb, ankit thukral
On Fri, Jan 02, 2004 at 03:56:18AM +0530, Ramana Radhakrishnan wrote:
> Now the remote side would have to understand the target floating point
> format / collect the values for
> the same and hence the actual computation would have to be target
> specific .2 options
> a. do all calculations in gdbserver
> b. collect all byte sequences and take care of it in gdb.
>
> Option b seems less expensive.
Yes, but sometimes it's not enough. In the example I gave you'd have
to do the memory reference at trace collection time. But I don't
think it's a real problem so option b is probably fine.
> That'd be PTRACE_EXIT_EVENT in the modern kernels.?Something that I
> missed out in my earlier mails.
Right.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Addition of remote tracepoints to gdb / gdbserver.
2004-01-01 22:56 ` Daniel Jacobowitz
@ 2004-01-01 23:16 ` Ramana Radhakrishnan
2004-01-03 19:47 ` Ramana Radhakrishnan
1 sibling, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2004-01-01 23:16 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb, ankit thukral
Daniel Jacobowitz wrote:
>On Fri, Jan 02, 2004 at 03:56:18AM +0530, Ramana Radhakrishnan wrote:
>
>
>>Now the remote side would have to understand the target floating point
>>format / collect the values for
>>the same and hence the actual computation would have to be target
>>specific .2 options
>>a. do all calculations in gdbserver
>>b. collect all byte sequences and take care of it in gdb.
>>
>>Option b seems less expensive.
>>
>>
>
>Yes, but sometimes it's not enough. In the example I gave you'd have
>to do the memory reference at trace collection time. But I don't
>think it's a real problem so option b is probably fine.
>
>
It might be cheaper to take option b .,for FPU less architectures That
could be another reason for sticking to option b.
Also regarding the AgentExpression code Generation problem that you
mentioned in your earlier mail , the byte code generated for the
following actions in the agent expressions is as
follows.
considering 2 globals i & j and we need to collect the value of i + j at
some trace point.
trace someprogram point
collect i + j
code generated seems to be equivalent to the following
Aopconst32 &i
Aopref32
Aopconst32 &j
Aopref32
aopadd
(where aopconst32 )
and aopadd is addition .
which is consistent with the manual
cheers
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Addition of remote tracepoints to gdb / gdbserver.
2004-01-01 22:56 ` Daniel Jacobowitz
2004-01-01 23:16 ` Ramana Radhakrishnan
@ 2004-01-03 19:47 ` Ramana Radhakrishnan
1 sibling, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2004-01-03 19:47 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb, ankit thukral
Hi ,
What are the semantics of breakpoints/ watchpoints during a trace
experiment ? Should not breakpoints be disabled during the
trace experiment ?I could not find any mention of this in the manual .
cheers
Ramana
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-03 19:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-01 21:33 [RFC] Addition of remote tracepoints to gdb / gdbserver Ramana Radhakrishnan
2004-01-01 21:47 ` Daniel Jacobowitz
2004-01-01 22:29 ` Ramana Radhakrishnan
2004-01-01 22:56 ` Daniel Jacobowitz
2004-01-01 23:16 ` Ramana Radhakrishnan
2004-01-03 19:47 ` Ramana Radhakrishnan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox