Hi,
This patch series introduce a concept "target set" in GDB. "Target
set" is described in HPD standard [1]. In "1.2.2 Process/Thread Sets",
"The concept of the target p/t set is used to restrict a debugger
command so that is applies to one, many, or all threads of control."
The command can be applied to processes and threads within the "target
p/t set".
Something similar is mentioned in [2], "Unlike a serial debugger in which
each command clearly applies to the only executing thread, TotalView can
control and monitor many threads with their PCs at many different locations.
The P/T set indicates the groups, processes, and threads that are the target
of the CLI command. No limitation exists on the number of groups, processes,
and threads in a set".
GDB does process/thread specification now, but in a piecemeal and
disorganized way. Some of GDB commands have done something to control
the scope of inferiors and threads. For example,
- "thread apply THREADS COMMAND", for example, "thread apply 1-2 bt"
it will apply "bt" to thread 1 and 2.
- detach/kill/remove inferiors, like "detach inferior 1 3"
it will apply "detach" command to inferior 1 and 3.
- break FOO thread 1
it will apply "break" command to thread 1.
In HPD, the "target set" can be defined explicitly by p/t set prefix
of command or implicitly by current p/t set. We propose to define
"target set" explicitly by command "scope" (we'll explain this decision below).
The equivalents of commands above are:
- scope t1-2 bt
- scope i1,i3 detach
- scope t1 break FOO
As we can see, the command syntax becomes:
[scope PTSET] COMMAND
Here are some underlying rationales of this design
1. "Target set" can only be defined by "scope PTSET" as a prefix
of command. Usually, there are four options to set "target set",
and the first three are mentioned in HPD [1].
a) "[all]> [t1] bt". Current p/t set is "all", and use "prefix
p/t set" to set "target set". We don't choose it because it
increases the complexity of command parsing.
b) "[t1]> bt". Current p/t set is t1, and use current p/t set to define
"target set". Without command output aggregation, this choice
is not user friendly. For example, if current set is "all",
and there are 1000 threads, user types command "bt", GDB will
show backtrace of all 1000 threads.
c) "[all]> scope t1 bt". Set the current set to t1 temporarily,
and "target set" is defined by it. We choose this option,
because user has to explicitly type "scope" it he/she wants
to use "target set", otherwise, GDB still behaves in the
traditional way.
d) The debugger manual clearly lists how "prefix p/t set" and "current
p/t set" affect "target p/t set". For example, in PGDBG, "the
command set is divided into thread disjoint subsets according to
how each command reacts to the current p/t-set" [3]. Commands are
divided to:
"Process level commands" Parallel by current p/t set or prefix p/t
set, for example, "cont", "next" and "step".
"Thread level" Parallel by prefix p/t set only, for example, "print"
and "bt".
"Global commands" No-parallel commands, for example, "enable" and
"disable".
We don't choose this way in GDB because user has to remember which
group each command is in.
2. Introduce "trigger set" to breakpoint, without "stop set".
The "target set" of break means the set of threads break command
can apply, in other words, it means the set of threads can trigger
the breakpoint. The "target set" of break command can be called
"trigger set" of the breakpoint created by this command. In HPD,
both "trigger set" and "stop set" are described, and also in
Pedro's initial ITSET implementation, "trigger set" and "stop set"
were supported. "Trigger set" means which threads are able to
trigger breakpoint, while "stop sets" means which threads stop
when the breakpoint is triggered.
We don't support "stop set" because:
a) it needs a lot of work in GDB on stopping/suspending threads,
b) "stop set" and "trigger set" are quite independent. Each one
can work without the other one. The "stop set" in TotalView is
quite simple, it is about "stop the thread hits breakpoint",
"stop the threads of the process in which a thread hits breakpoint",
or "stop all processes in a group when execution reaches the
breakpoint" [4]. PGDBG Debugger [3] doesn't support "stop set"
either.
so, we propose to implement "trigger set" first in breakpoint.
3. The syntax of PTSET is still incomplete.
It is not the focus of this patch series to get a consensus on
PTSET syntax, and its discussion should go to a separate thread.
The PTSET syntax used in this patch is a subset of PTSET syntax,
which everyone would agree with, and is sufficient for "target
set". It leaves the open space to complete the syntax step by
step.
The patches are stolen from Pedro's initial implementation, with some
revise and modification. After my last ITSET proposal was rejected in
May last year, I kept thinking how to get it, or part of it,
acceptable. The major reason that patches are unacceptable is that
we want to address too many issues in one patch series. These issues
are:
1) Get an complete PTSET syntax,
2) Improve GDB on stopping/suspending arbitrary threads,
3) Support "trigger set" and "stop set" in breakpoint,
4) Support execution control regards of PTSET, like "cont" or
"step".
Each of them is not a small piece of work, in terms of code and
discussion. We'd better to address them one by one. This patch
series get touch on part of #1 and #3. IMO, it is a reasonable set
to go in, and unfreeze the P/T SET work. Patch 1 is about the P/T SET,
patch 2 is to add a command "scope". Patch 3 and 4 are to teach
two commands "break" and "bt" be aware of "target set". Patch 5
is about test case. The doc and NEWS entry is not included in
the patch, and I'll add them if this approach is acceptable.
Once this series go in, we can do something more:
1. Transform "thread apply THREADS COMMAND" to
"scope PTSET COMMAND".
2. Transform "detach/kill/remove inferior INFERIORS" to
"scope PTSET detach/kill/remove inferior".
3. Teach more commands, such as "gcore" and "kill" to be aware of
PTSET.
What do you think?
[1] HPD Version 1 Standard.http://web.engr.oregonstate.edu/~pancake/ptools/hpdf/draft/
[2] TotalView User Guide.
[3] PGDBG Debugger Guide.http://www.pgroup.com/doc/pgdbgug.pdf
[4] TotalView Reference Guide.