I/T Sets
Contents
A.k.a., inferior/thread sets, inferior/process/thread sets, inferior/process/core/thread sets, inferior/process/ada task/thread sets, argh, you get the point.
There's been preliminary work posted. The original version is here:
A few minor revisions have been later posted:
However, that work is still WIP and not complete.
1. Getting the code / Helping
Discussions are held on the main GDB mailing lists. Patches should be posted to the gdb-patches mailing list. Work is being committed directly to the mainline (i.e., there's no special feature branch).
2. Sub tasks
For itsets to be actually useful enough that we can be experiment and be sure the syntax is easy, comfortable and powerful enough, we need all-stop-on-top-of-non-stop. However, not all targets will support that, so the itsets syntax must be able to cope with such targets.
- The proposed user interface needs to be carefully rethought through. E.g., for resumptions commands, it's a nuisance to always have to explicitly specify the "apply set" and the "run free set". There's also a disconnect of concepts between the current thread, and the selected scope. A concept of "scope width" like other debuggers have might prove to be essential, for it may allow easier more natural syntax for specifying the two sets as one.
Thread IDs of all processes in GDB are in a single shared number space. This is quite a nuisance, and confusing to users. E.g., a user might expect that p2.1 refers to thread 1 or process 2, and p2.1 refers to thread 1 of process 2, but that's not how it works. If we do want to switch to a model where the thread number space is unique per inferior, that affects the current proposed itsets syntax. This should be carefully considered, and possibly pushed before the itsets work. (To keep backwards compatibility with MI, each thread could have two identifiers -- one global ID always incrementing, and a process-private ID, that starts at 1 for each process). Done in 7.11. [Pedro]